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Preface 


This  guidebook  describes 

*  The  importance  Human  Systems  Integration  (HSI)  to 
the  flight  of  Unmanned  Aircraft  System  (UAS)  in  non- 
segregated  airspace 

*  Activities  that  can  help  identify  where  the  key  human 
contributions  to  UAS  performance  and  safety  are  likely 
to  occur 

•  How  to  manage  the  HSI  input  into  development  of 
UAS 

•  Techniques  that  can  be  used  to  apply  HSI 


This  guidebook  is  aimed  at 
NATO  and  Industry 
personnel  who  need  to 
address  and  resource  the 
human  issues/risks  in  the 
design,  implementation,  and 
operation  of  Unmanned 
Aircraft  Systems 


Distribution  A:  Approved  for  public  release;  distribution  unlimited. 
88ABW  Clear  10/21/2013;  88ABW-2013-4442 
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The  processes  specified  in  the  guidebook  are 
both  goal  and  risk-based.  Overarching  HS1 
goals  that  must  be  satisfied  in  every  UAS 
project  are  identified.  Provided  the  goals  are 
achieved,  the  means  by  which  they  are 
achieved  can  be  tailored  to  the  circumstances 
of  individual  UAS  projects.  As  a 
consequence,  the  extent  and  depth  of  HS1 
activities  should  be  tailored  to  the  degree  of 
project  risk  presented  human-related 
considerations.  In  this  way,  the  process 
supports  the  development  of  cost-effective 
UAS  that  are  safer,  have  increased  mission 
effectiveness  and  reliability,  therefore 
meeting  requirements  for  integration  into 
non-segregated  airspace. 

The  main  users  of  this  guidebook  will  be  project  managers  designing,  developing,  and/or  procuring  UAS. 
This  guidebook  therefore  addresses  Human-Related  considerations  and  HS1  activities  to  allow  managers 
to  understand  their  relevance  and  importance  to  the  systems  engineering  process  as  a  whole.  Nonetheless, 
all  parties  involved  in  UAS  development,  including  the  end-users  of  UAS,  should  find  this  guidebook 
relevant. 

This  guidebook  was  prepared  by  the  HS1  Specialty  Team  for  the  UAS  Flight  in  Non-Segregated  Airspace 
(FINAS)  Working  Group,  Joint  Capability  Group  for  UAS  (JCGUAS).  The  particular  focus  of  the 
guidebook,  which  is  part  of  the  overall  work  package  of  FINAS,  was  the  provision  of  guidance  to 
improve  consideration  of  the  human  component  of  UAS  to  decrease  human  performance-related  accidents 
and  incidents  and  improve  safety,  thereby  facilitating  routine  flight  of  UAS  in  non-segregated  airspace.  It 
was  the  product  of  FINAS  study  number  4685,  which  baselined  the  United  Kingdom  Ministry  of  Defence 
Standard  00-250,  Human  Factors  for  Designers  of  Systems  (2008),  and  extracted  the  high-level  process- 
related  elements  that  were  applicable  to  a  generic  systems  engineering  framework  for  designing  and 
procuring  a  UAS. 


Reference . PFP(NNAG-JCGUAV)D(2009)0002n 

Version . 1 
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Definition  of  Terms 


Throughout  this  document,  terminology  is  used  that  may  mean  different  things  to  different  people.  The 
definitions  listed  in  Table  1  are  intended  to  clarify  and  standardize  the  terminology  used 

All  of  the  definitions  listed  are  referenced  in  ISO  15288:2008,  Systems  and  software  engineering  - 
System  life  cycle  processes.  The  first  column  provides  the  term  as  it  may  be  used  in  other  standards  or 
references,  the  second  column  provides  the  term  as  it  is  used  in  this  document,  and  the  third  column 
provides  a  definition  of  the  term. 

Table  1.  Definition  of  Terms  Used  in  this  Document 


Traditionally  Used 
Term 

As  Used  in  this 
Document 

Definition 

Guidebook 

Guidebook 

A  non-directive  reference  book  of  a  particular  subject  or  a 
compilation  of  factual  data  and  instructional  material  not 
subj  ect  to  frequent  revision. 

Human  Systems 
Integration 

HSI 

A  systematic  process  of  identifying,  tracking,  and  resolving 
human-related  issues  ensuring  a  balanced  development  of 
both  technologies  and  human  aspects  of  complex  systems. 

Life -cycle 

Life -cycle 

Evolution  of  a  system,  product,  service,  project  or  other 
human-made  entity  from  conception  through  retirement  in 
acquisition. 

Stakeholder 

Stakeholder 

An  individual  or  organisation  having  a  right,  share,  claim,  or 
interest  in  a  system  or  in  its  possession  of  characteristics  that 
meet  their  needs  and  expectations. 

System 

System 

A  combination  of  interacting  elements  organized  to  achieve 
one  or  more  stated  purpose(s)  (a  system  may  be  considered 
as  a  product  or  the  services  it  provides). 

System  Acquirer 

Acquirer 

Stakeholder  that  acquires  or  procures  a  product  or  service 
from  a  contract  (e.g.,  Government  or  Industry). 

System  User 

User 

An  individual  or  group  that  benefits  or  interacts  with  the 
system,  i.e.  operators,  maintainers,  and  support  personnel. 

System  Developer 
(Supplier,  Solution 
Provider) 

Contractor 

An  organisation  or  individual  that  enters  into  an  agreement 
with  the  acquirer  and  develops  a  system  or  product. 

Trade-off 

Trade-off 

Decision  making  actions  that  selects  various  requirements 
and  alternative  solutions  on  the  basis  of  net  benefit  to  the 
stakeholder. 

Distribution  A:  Approved  for  public  release;  distribution  unlimited. 
88ABW  Clear  10/21/2013;  88ABW-2013-4442 
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Introducing  Human  Systems  Integration 


Why  implement  HSI  in  Unmanned  Aircraft  Systems? 


People  are  the  key  component  of  any  defence 
system  —  and  this  is  no  less  the  case  for 
unmanned  aircraft,  where,  despite  the  term 
“unmanned,”  much  human  involvement  is 
required  to  achieve  desired  mission  effectiveness. 
The  field  of  unmanned  aircraft  is  clearly  an 
emerging,  high  growth  sector  within  aviation.  As 
with  any  new  area  of  innovation,  the  initial  focus 
in  unmanned  aviation  has  centered  on  advancing 
the  enabling  technologies  and  developing  the 
procedures  for  their  operation  so  as  to  gain  a 
competitive  advantage. 


As  various  organisations  have  developed  and  employed 
increasingly  sophisticated  unmanned  aircraft  over  the 
past  decade,  there  has  been  a  growing  understanding  of 
unmanned  aircraft  as  complex,  distributed  systems 
rather  than  simply  aircraft  —  that  is,  the  realisation  that 
there  is  much  more  than  simply  an  aircraft  in  question. 
This  understanding  is  formally  captured  in  the  current 
term  of  reference  of  Unmanned  Aircraft  System  (UAS). 
From  a  total  system  perspective,  one  should  appreciate 
that  a  UAS  is  comprised  of  an  unmanned  aircraft, 
surface  components,  and  other  architectural  elements, 
each  with  their  own  attributes  and  which  collectively 
interact  to  exhibit  emergent  system-level  properties  that 
are  of  value  to  various  system  stakeholders. 

Implicit  in  this  systems  view  should  be  the  comprehension 
that  the  Ground  Control  Station  (GCS),  inclusive  of  the  human  crewmembers,  plays  a  significant  role  in 
determining  the  overall  system-level  properties  of  a  UAS  to  include  system  safety.  Also  couched  in  this 
systems  view  is  the  acknowledgement  that  development  of  UAS  needs  to  be  coordinated  through  a  systems 
engineering  process.  Even  when  a  systems  engineering  approach  is  adopted,  however,  it  is  often  constrained  in 
scope  to  the  technological  system.  This  observation  is  a  significant  problem,  because  contrary  to  popular 
opinion,  UAS  have  not  removed  the  human  element  from  the  system.  Instead,  UAS  provide  the  option  for  the 
human  to  no  longer  necessarily  be  co-located  within  the  physically  dynamic  components  of  the  system. 
Similarly,  highly  automated  systems  allow  modification  rather  than  elimination  of  the  role  of  humans,  such  as 
by  decreasing  prerequisite  skills  and  aptitudes  or  allowing  increased  span  of  control. 


Distribution  A:  Approved  for  public  release;  distribution  unlimited. 
88ABW  Clear  10/21/2013;  88ABW-2013-4442 
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Work 

Environment 


Human  Systems  Integration 


As  in  manned  systems,  the  essential  role  of  the  human 
in  UAS  is  to  provide  the  overarching  situation 
awareness  and  contextually  responsive  command  and 
control  for  the  system.  To  accomplish  these  functions, 
the  human  must  interact  with  the  system  at  some  point 
in  its  operation  and  use  some  form  of  system 
interface.  It  is  therefore  essential  for  both  mission 
effectiveness  and  safety  that  the  human  be  fully 
integrated  into  UAS  starting  at  system  conception. 
This  requires  attention  to  all  elements  of  HS1  when 
developing,  acquiring,  and  operating  UAS. 


Factors 

Engineering 


Human 

Systems 

Integration 


Manpower/ 

Personnel 


Organisational 
and  Social 


It  is  worthwhile  to  explicitly  define  here  what  is  meant  by  HS1  since  many  individuals  view  it  narrowly  as  the 
interface  of  the  human  and  the  machine,  synonymous  with  human  factors  engineering  and  traditional  cockpit 
design.  This  view  actually  encompasses  only  a  single  element  of  HS1.  Broadly,  HS1  is  based  on  the 
understanding  that  people  are  the  critical  elements  within  systems  and  adopting  a  human-centric  perspective  of 
systems  increases  productivity  and  safety  whilst  decreasing  costs.  HS1  involves  the  identification  and  tradeoff 
of  the  human-related  issues  that  could  impact 
heavily  upon  system  perfonnance.  To  ensure 
that  all  issues  are  considered,  these  human- 
related  issues  are  categorized  into  five  main 
areas  or  domains  (see  figure  to  the  right);  and  a 
core  principle  of  HSI  is  the  necessity  for  those 
developing,  acquiring,  and  operating  systems  to 
maintain  a  holistic  perspective  of  these  domains. 

No  one  domain  should  be  considered  in  isolation 
—  rather,  they  need  to  be  related  to  each  other. 

Any  decision  in  one  of  the  domains  almost 
certainly  impacts  on  another  domain. 

Safety  and  Airspace  Integration 


For  proponents  of  operating  UAS  within  the  world-wide  airspace  structure  in  a  non-segregated  fashion,  such  as 
the  NATO  Joint  Capability  Group  for  Unmanned  Aircraft  Systems  (JCGUAS),  a  significant  area  of  interest  is 
system  safety.  With  the  growing  emphasis  on  UAS  mishap  investigation  and  analysis,  human  error  (i.e., 
human  performance  failure)  has  been  shown  to  be  a  significant  contributor  to  UAS  safety-related  events. 

Based  on  the  concept  of  HSI  developed  above,  any  effort  to  address  UAS  system  safety  must  involve  a  holistic 
consideration  of  the  other  HSI  domains,  such  as  human  factors  engineering,  manpower/personnel,  and  training. 
This  assertion  represents  nothing  new  and  holds  equally  true  in  the  case  of  traditional,  manned  aviation. 
However,  in  manned  aviation  personnel  and  training  are  fairly  tightly  defined  by  existing  regulations  and 
standards,  thereby  allowing  a  relatively  prescriptive  approach  to  the  human  factors  engineering  of  human- 
system  interfaces  in  achieving  desired  system  safety  levels.  In  contrast,  significantly  greater  variability 
presently  exists  in  terms  of  personnel  and  training  as  they  apply  to  UAS,  making  a  prescriptive  approach  to  the 
design  of  the  GCS  far  less  tractable.  Rather,  human  factors  engineering  decisions  need  to  be  considered  in  light 
of  the  overall  performance,  safety,  and  cost  trade  space  that  exists  between  the  human  factors  engineering, 
manpower/personnel,  and  training  domains,  among  others.  Consequently,  a  repeatable  process  solution  to  GCS 
design  that  explicitly  considers  this  trade  space  is  preferable  so  that  potentially  desirable  innovation  is  not 
unnecessarily  limited. 


Distribution  A:  Approved  for  public  release;  distribution  unlimited. 
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Asa  result  of  its  first  investigation  of  an  accident 
involving  an  unmanned  aircraft,  the  U.S.  National 
Transportation  Safety  Board  (NTSB)  issued  a  total 
of  22  safety  recommendations  to  address  what 
NTSB  Chairman  Mark  V.  Rosenker  said  were  "a 
wide  range  of  safety  issues  involving  the  civilian 
use  of  unmanned  aircraft."  The  safety 
recommendations  stemmed  from  the  April  25,  2006, 
accident  in  which  a  Predator  B  operated  on  a 
surveillance  mission  by  the  U.S.  Customs  and 
Border  Protection  crashed  in  a  sparsely  populated  residential  area  near  Nogales,  Arizona.  The 
Safety  Board  determined  that  the  probable  cause  of  the  accident  was  the  pilot's  failure  to  use 
checklist  procedures  when  switching  operational  control  from  a  console  that  had  become 
inoperable  due  to  a  "lockup"  condition,  which  resulted  in  the  fuel  valve  inadvertently  being  shut 
off  and  the  subsequent  total  loss  of  engine  power,  and  a  lack  of  a  flight  instructor  in  the  Ground 
Control  Station.  At  the  Board  meeting,  the  NTSB  highlighted  several  areas  of  particular  interest 
including:  the  design  and  certification  of  the  unmanned  aircraft  system;  pilot  qualification  and 
training;  the  integration  of  UAs  into  the  air  traffic  management  system;  and  audio  records  of  all 
UA  operations-  related  communications.  (Homeland  Security  and  Defense,  October  17,  2007) 
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Introduction  to  Human  Systems  Integration  Domains 


Human  Systems  Integration 
Domains 

Human  Systems  Integration  involves  the 
identification  and  tradeoff  of  the  human-related 
issues  that  could  impact  acquisition  processes.  These 
human-related  issues  are  categorised  into  five  main 
areas,  or  domains,  which  essentially  form  a  checklist 
of  issues  that  need  to  be  considered. 

These  issues  are  not  prescriptive  and  the  domains 
should  not  be  considered  as  separate  entities,  rather 
they  need  to  be  related  to  each  other.  Any  decision  in 
one  of  the  domains  can  easily  impact  another  domain. 
Stakeholders  from  all  the  domains  need  to  come 
together  early  in  the  programme  and  conduct  an 
Early  Human  Factors  Analysis  to  identify  the  risks 
and  trade-offs  in  order  to  resolve  these  later  in  the 
project. 


Distribution  A:  Approved  for  public  release;  distribution  unlimited. 
88ABW  Clear  10/21/2013;  88ABW-2013-4442 


12 


Manpower/Personnel 


The  Manpower/Personnel  domain  concerns  the  number  of  men  and 
women,  military,  civilian,  and  contractors,  required  and  available  to 
operate  and  maintain  the  UAS  under  consideration.  It  considers  the 
aptitudes,  experience,  and  other  human  characteristics,  including 
body  size  and  strength,  necessary  to  achieve  optimum  system 
performance.  This  domain  also  includes  the  necessary  selection 
processes  required  for  matching  qualified  personnel  to  the 
appropriate  task. 


Some  important  HSI  issues  to  consider  within  this  domain  are: 

*  Wartime/peacetime  manpower  requirements 

*  Deployment  considerations 

*  Operating  strength 

*  Manning 

*  Personnel  selection  and  classification 

*  Cognitive,  physical  and  educational  profiles 

*  Accession  and  attrition  rates 

*  Qualified  personnel  when  and  where  needed 

*  Individual  differences/variability 

*  Supervision 

*  Manpower  mix 

*  Language  aptitude 
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Training 

Training  embraces  the  specification  and  evaluation  of  the  optimum  combination  of  instructional 
systems;  education;  and  on-the-job  training  required  to  develop  the  knowledge,  skills  and  abilities 
(e.g.,  social/team  building  abilities,  soft  skills,  competencies)  needed  by  the  available  personnel 
to  operate  and  maintain  the  UAS  under  consideration  to  a  specified  level  of  effectiveness  under 
the  full  range  of  operating  considerations. 

Some  important  HS1  issues  to  consider  within  this  domain  are: 

•  Training  pipeline  flow 

•  Training  tasks  and  training  development  methods 

•  Media,  equipment  and  facilities 

•  Operational  tempo 

•  Continuity  training,  refresher  training,  and  core  competency-based  training 

•  Teamwork/crew  resource  management 

•  Balance  of  live  flying  training,  embedded  training,  and  simulator  training 

•  Licensing  and  certification  of  individuals 

•  Evaluation/quality  assurance  of  training 
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Human  Factors  Engineering 


Human  factors  are  the  user’s  cognitive,  physical,  sensory, 
and  team  dynamic  abilities  required  to  perform  UAS- 
specific  operational,  maintenance,  and  support  job  tasks. 
Human  Factors  Engineering  (HFE)  covers  the 
comprehensive  integration  of  human  characteristics  into 
UAS  design,  including  all  aspects  of  workstation  and 
workspace  design  and  system  safety.  The  objective  is  to 
maximise  user  efficiency  whilst  minimising  the  risk  of 
injury,  to  personnel  and  others. 


Some  important  HS1  issues  to  consider  within  this  domain  are: 

•  Compatibility  of  design  with  anthropometries  and  biomedical  criteria 

•  Workload,  situational  awareness  and  human  performance  reliability 

•  Human-Machine  Interface  (HM1) 

•  Effects  of  design  on  skill,  knowledge,  and  aptitude  requirements 

•  Design  driven  human  performance 

•  Information  processing 

•  Cognitive  fatigue 

•  HM1  supports  trust  in  automation 

•  Employment  of  automation 

•  Implementation  of  decision-aiding 

•  Design  to  enable  maintenance  tasks 

•  Human  error 
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Safety  and  Health 


Safety  and  Health  is  the  process  of  applying  expertise  to  minimise  safety  risk  to  UAS  users  and 
bystanders  occurring  as  a  result  of  the  system  operating  or  functioning  in  either  a  normal  or 
abnormal  manner.  UAS  design  features  should  serve  to  minimise  the  risk  of  injury,  acute  or 
chronic  illness,  and/or  discomfort  of  personnel  who  operate,  maintain,  or  support  the  system. 
Likewise,  design  features  should  mitigate  the  risk  for  errors  and  accidents  resulting  from 
degraded  job  performance.  Prevalent  safety  and  health  issues  include  noise,  chemical  safety, 
vibration,  ionsing  and  non-ionising  radiation,  and  human  factors  issues  that  can  create  chronic 
disease  and  discomfort  such  as  repetitive  motion  diseases.  Human  factors  stresses  that  create  risk 
of  chronic  disease  and  discomfort  overlap  with  occupational  health  considerations.  These  issues 
directly  impact  crew  morale. 

Some  important  HS1  issues  to  consider  within  this  domain  are: 

•  Total  system  reliability  and  fault  reduction/error  tolerance 

•  Safety  culture 

•  Occupational  injuries  and  illnesses 

•  Health  hazards  induced  by  systems,  environment,  or  task  requirements 

•  Shift  work,  disturbed  biological  rhythms,  and  physiological  fatigue 

•  T elewarfare  and  sustained,  in-garrison  operations 
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Organisational  and  Social 


Organisational  complexity  is  a  key  feature  of  networked  enabled  capabilities  typified  by  modem 
UAS.  Networked  enabled  capabilities  necessitate  building  trust  and  confidence  between  people 
in  separate  organisations  who  need  to  collaborate  on  a  distributed  and  temporary  basis  for 
effective  operations.  Consequently,  Organisational  and  Social  is  the  process  of  using  all  available 
tools  and  techniques  drawn  from  relevant  information  and  behavioural  science  disciplines  to 
enable  people  to  adapt  to  a  more  open  culture  that  requires  greater  sharing  and  trust  between 
colleagues  and  coalition  partners. 

Some  important  HS1  issues  to  consider  within  this  domain  are: 

*  Distributed  teams  and  shared  situation  awareness  (e.g.,  remote  split  operations) 

*  Differences  in  cultural,  spiritual,  and  ethical  norms 

*  Trust  and  information  sharing  to  include  means  and  standards  of  communications 

*  Definition  of  roles,  responsibilities  and  authorities 

*  “Soft”  interoperability 

*  Alternative  organisational  configurations 

*  Multi-national/multi-service  interoperability 

*  Language 
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Human  Systems  Integration  Process 


HSI  is  about  mitigating  risk,  managing  safety,  improving  performance,  and  ensuring  the  satisfaction  and 
well-being  of  personnel  operating,  maintaining,  and  supporting  a  UAS.  To  do  this  successfully,  HSI 
activities  must  be  related  to  the  overall  systems  engineering  approach  used  in  acquisition.  Figure  1 
illustrates  how  key  HSI  activity  stages  map  to  the  system  engineering  life -cycle  stages.  This  figure  is 
further  broken  out  in  the  following  sections  of  Pre -Development  Decision  HSI  Activities  and  Post- 
Development  Decision  HSI  Activities. 
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HSI  Activity  Stage 


System  Life- 
Cycle  Stages 


Figure  1 .  HSI  activity  stages  mapped  to  the  system  engineering  life-cycle  stages 

(. Adapted  from  UK  MoD  Defence  Standard  00-250) 
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HSI  Process  Goals 


In  all  UAS  acquisition  projects,  the  following  HSI  goals  shall  be  fully  pursued  to  achieve  satisfactory 
outcomes.  All  HSI  activities  that  are  undertaken  shall  relate  to  and  support  one  or  more  of  the  itemised 
goals. 


»*  Planned  and  managed  consideration  of  Human-Systems  and  People-Related  considerations 
(including  risks,  issues,  constraints,  assumptions,  etc.)  from  the  very  outset  of  a  UAS  project, 
and  subsequently  throughout  the  life  cycle. 

**  Systematic  treatment  of  Human-Systems  and  People-Related  considerations  through  the  life  of 
the  UAS,  including  the  early  stages  of  In-Service  operations  and  final  disposal. 

**  Systematic,  rigorous  and  formal  capture,  specification  and  management  of  People-Related 
Requirements  necessary  to  provide  the  required  UAS  capability. 

»*  The  adoption  of  a  User-centred  design  approach  as  defined  in  ISO  9241-210:2010,  or  an  agreed 
variant  where  such  is  decided  to  be  more  appropriate  to  the  UAS  project  strategy. 

**  The  use  of  established  Human-Systems  principles,  accepted  best  practice,  and  suitable  methods 
tools  and  techniques  and  data. 

**  Design  to  match  the  Context  of  Use. 

**  Design  to  match  User  Characteristics. 

**  Design  to  match  User  Organisation  characteristics. 

**  Design  to  meet  User  needs. 

»*  Adoption  of  a  multi-disciplinary  approach. 

**  Involvement  of  Users  in  system  and  equipment  design  and  evaluation. 

**  The  iteration  of  design  solutions  so  as  to  optimise  the  Solution  against  People-Related 

**  Requirements  and  People-Related  constraints. 

**  Formal  scrutiny,  assessment  and  acceptance  of  Human -Systems  aspects  of  the  Solution. 

These  high-level  goals  can  be  viewed  as  a  hierarchical  set,  achieved  through  a  series  of  sub-goals, 
activities  and  data  in-feeds.  Figure  2  illustrates  this  hierarchy.  When  each  of  the  individual  goals,  sub¬ 
goals  and  high-level  goals  have  been  satisfactorily  addressed,  a  project  may  claim  that  HFI  has  been 
satisfactorily  achieved. 
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Top  Level  Goal 


Sub  Goals 


Individual  Goals 


Figure  2.  Overarching  HSI  Goal  Structure  (Adapted  from  DefStan  00-250) 
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Pre-Development  Decision  HSI  Activities 


This  section  provides  a  functional  decomposition  of  the  Pre -Development  Decision  HSI  Activities. 
Figure  3  illustrates  the  decomposition  of  the  steps  required  in  these  activities  and  shoidd  be 
referenced  in  the  following  sections:  1)  Establishing  the  HSI  Baseline,  2)  Early  Human  Factors 
Analysis,  3)  Human  Views,'  and  4)  Human-Related  Requirements. 


I 


Figure  3.  Decomposition  of  pre-development  decision  HSI  activities 

(Adapted  from  UK  MoD  Defence  Standard  00-250) 


f  The  NAT O  Human  View  (HV)  is  a  supplementary  view  to  existing  architectures,  providing  an  additional 
set  of  eight  products  that  augmentthe  DoDAF  (or  similar)  systems  architecture  products  required  of 
systems  engineers.  The  purpose  of  the  HV  is  to  capture  human  requirements  and  to  inform  on  how 
humans  interact  with  systems  (NATO  Human  View  Quick  Start  Guide). 
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1.0  Establish  HSI  Baseline 


The  objective  of  this  activity  is  to  collate  the  information  necessary  to  form  a  baseline  description  of  the 
key  HSI-related  considerations  that  will  be  assessed  during  an  Early  Human  Factors  Analysis.  Depending 
on  the  life -cycle  stage  of  the  UAS  project,  differing  levels  of  baseline  are  possible. 

1.1  Establish  Project  Concept  and  Objectives 

During  this  initial  step,  collect  any  documents  or  known  assumptions  that  may  have  an  influence 
on  the  human  component  of  the  emerging  UAS-related  capability.  This  would  include  identifying 
all  material  defining  the  baseline,  such  as  the  fixed  inputs,  background,  objectives  and  scope  of 
the  UAS  project  as  well  as  relevant  standards.  When  reviewing  these  materials,  emphasis  should 
be  on  identifying  content  relevant  to  the  HSI  domains  and  determining  what  is  ‘core’  to  HSI; 
identifying  what  is  known  about  human-related  issues;  determining  what  is  ‘fact’  and  what  is 
‘assumption’  and  document  both;  note  any  likely  HSI  distinctions  between  options  under 
consideration;  and  identify  areas  where  there  is  no  information  on  HSI  matters  and  decide  where 
to  fill  the  gaps  (HFI  Practical  Guidance  for  IPTs,  2001). 

1.2  Establish  HSI  Strategy 

The  HSI  Strategy  shows  how  the  key  goals  of  the  HSI  effort  help  achieve  overall  UAS  project 
goals.  It  is  based  on  a  clarified  and  quantified  understanding  of  the  main  HSI  issues  and  risks  in 
the  context  of  the  specific  UAS  acquisition  strategy.  The  issues  will  also  direct  the  Early  Human 
Factors  Analysis  (EHFA),  which  is  both  a  management  approach  and  technical  activity  (UK  MoD 
HFI  Process  Handbook,  2007). 

The  development  of  an  HSI  Strategy  should  be  initiated  early  in  the  UAS  acquisition  process 
when  the  need  for  a  new  UAS  capability  or  improvements  to  an  existing  UAS  is  first  established. 
It  should  describe  the  technical  and  management  approach  for  meeting  HSI  parameters  in  the 
capabilities  documents  and  identify  and  provide  ways  to  manage  any  HSI-related  cost,  schedule, 
or  performance  issues  that  could  adversely  affect  UAS  programme  execution  (US  DoD  Defense 
Acquisition  Guide,  2011). 


The  aim  of  the  HSI  Strategy  is  to  ensure  that  the  human  element  of  the 
UAS  is  fully  considered  when  generating  and  developing  user 
requirements  and  the  system  requirements  document. 
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1.3  Establish  Context  of  Use 


Context  of  Use  is  defined  as  the  users,  tasks,  equipment  (hardware,  software,  and  materials),  and 
the  physical  and  social  environments  in  which  a  UAS  is  used  (ISO  9241-1 1:2000).  Successful 
HSI  requires  the  contractor  to  demonstrate  that  the  UAS  design  is  based  on  a  systematic  analysis 
and  understanding  of  the  expected  context  of  use  for  the  UAS  capability  (UK  MoD  Def  Stan  00- 
250,  2008). 

The  purpose  of  the  Context  of  Use  is  to  clarify  and  communicate  the  user 
characteristics  and  tasks,  and  identify  the  technical,  organisational,  and 

physical  environment. 

Understanding  the  Context  of  Use  guides  and  informs  early  design  decisions,  provides  a  firm 
basis  for  more  detailed  equipment  design  decisions,  and  provides  a  basis  for  evaluation  of  the 
resulting  UAS.  This  understanding  is  required  for  new  UAS  as  well  as  upgrades  and  capability 
enhancements  to  existing  UAS,  where  available  context  of  use  information  may  need  to  be 
checked  and  validated. 

Context  of  Use  information  embraces  many  dimensions.  These  include  physical  factors, 
organisational  factors  and  social  and  psychological  factors  such  as: 

•  Physical  environment 

•  Cultural  and  social  environment  (e.g.,  work  practices,  attitudes,  organisational  structure) 

•  Attributes  of  the  wider  technical  environment 

•  Legal  and  regulatory  environment 

•  Shared  situational  awareness 

•  Trust  and  information  sharing 

•  Alternative  organisational  configurations 

•  Existing  user  roles,  responsibilities,  and  work  management  hierarchies. 

1.3.1  Identify  Missions  and  Operational  Scenarios 

Operational  scenarios  form  one  element  of  the  capability  requirement.  Scenarios  specify 
conditions  under  which  the  capability  must  be  provided.  Mission  and  scenario  descriptions 
underpin  much  HSI  work  -  from  EHFA  through  the  ‘person  in  the  loop’  simulation  (UK  MoD 
Def  Stan  00-250,  2008). 

Mission  analysis  is  a  contributor  to  the  Context  of  Use  analysis  process,  providing  operational 
scenarios  that  feed  the  EHFA  process  and  other  processes  that  require  Context  of  Use  information 
needed  to  establish  the  ‘baseline’.  From  the  baseline,  the  designer  can  then  assess  the  impact  of 
the  human-related  risks. 

1.3.2  Develop  Project-Specific  Target  Audience  Description 

The  Target  Audience  Description  (TAD)  is  a  living  document,  started  early  in  and  becoming  more 
specific  throughout  a  UAS  project  lifecycle.  It  describes  the  capabilities,  limitations  and 
characteristics  of  personnel  who  will  operate,  maintain  and  support  the  UAS  being  designed  and 
developed.  It  integrates  material  from  various  “owners”  who  must  be  considered  as  stakeholders 
and  included  fully  in  the  review  process  (UK  MoD  HFI  Process  Handbook,  2007).  When 
establishing  the  TAD,  HSI  practitioners  should  verify  whether  there  are  any  recruitment  or 
retention  trends  or  demographic  changes  that  could  alter  the  characteristics  of  the  user  population 
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over  the  life  of  the  UAS.  HS1  analysts  should  consult  with  the  personnel  community  and  verify 
whether  there  are  new  personnel  policies  that  could  significantly  alter  the  scope  of  the  user 
population  (US  DoD  Defense  Acquisition  Guidebook,  2011).  The  TAD  includes  information 
such  as  (UK  MoD  HFI  Process  Handbook,  2007): 

•  Which  service/branch  users  will  be  drawn  from 

•  The  range  of  ranks  and  specialist  areas  involved 

•  Body  size/strength 

•  Physical  skills 

•  Knowledge/mental  skills 

•  Personal  attributes 

•  Educational  background 

•  Experience 

•  Training  objectives 

•  Career  progression 

•  Summary  of  key  tasks  personnel  will  need  to  perform 

•  Description  of  the  environment  personnel  will  operate  in. 

1.4  Analyse  Legacy  System  Data  and  Feedback 

Analysing  predecessor  systems  —  manned  or  unmanned  —  provides  insight  into  both  positive 
and  negative  aspects  of  a  system  design,  providing  the  data  needed  to  establish  Lessons  Learned. 
Much  effort  will  be  directed  to  identifying,  assembling  and  analysing  information  which  may 
include  briefings,  equipment  failure  reports,  and  safety  logs.  Managing  information  voids  may  be 
a  maj  or  part  of  this  effort.  Information  may  not  always  be  available  in  documentary  form  and 
may  need  to  be  obtained  from  users  and  subject  matter  experts.  Precursor  activities  will  be  to 
define  the  scope  of  the  predecessor  system(s)  under  consideration  and  to  define  the  scope  of  their 
Context  of  Use  information  that  is  relevant  to  the  current  project.  Analysis  techniques,  applied  to 
predecessor  system(s),  that  are  useful  for  supporting  development  of  Context  of  Use  for  the 
current  project  include  the  following: 

•  Mission  Analysis 

•  Function  Analysis 

•  Design  Scenario  Analysis 

•  Operational  Scenario  Description 

•  Mission-critical  Task  Identification 

•  Operability  Criteria  Definition 

•  Information  flows. 


2.0  Early  Human  Factors  Analysis 

Early  Human  Factors  Analysis  (EHFA)  is  a  key  HSI  tool  and  an  essential  component  of  initial  UAS 
project  development  activities.  Its  purpose  is  to  identify  human-related  issues  and  risks.  HSI 
activity  planning  should  be  based  on  the  results  of  EHFA. 

Ideally,  EHFA  is  conducted  early  in  a  UAS  project  lifecycle.  However,  the  primary  consideration  in 
EHFA  is  that  it  must  embrace  the  whole  UAS,  even  if  full  or  in-depth  analysis  is  not  possible  in 
every  area  due  to  immaturity  in  a  system  design.  Early  in  the  lifecycle,  human  issues  are  often 
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missed  but  there  can  be  high  gains  if  they  are  caught.  Conducting  an  EHFA  should  never  be 
omitted  on  the  basis  that  “it  is  now  too  late”. 

The  greatest  value  is  obtained  by  the  early  involvement  of  HS1  specialists.  Although  tools  have 
been  developed  to  assist  with  EHFA,  the  nature  of  the  approach  requires  an  open,  questioning,  free- 
thinking  and  possibly  intuitive  exploration  of  human-related  issues  rather  than  the  application  of  a 
prescriptive  or  mechanistic  process  (UK  MoD  Def  Stan  00-250,  2008). 


2.1  Conduct  Early  Human  Factors  Analysis 

The  EHFA  process  comprises  a  simple  three-stage  approach  which  focuses  effort  and  produces  an 
output  in  support  of  HS1  planning.  These  stages  include:  a)  Establish  the  HS1  Baseline  (discussed 
in  detail  in  section  1.0),  b)  Identify  the  HS1  issues  and  record  in  a  HS1  Issues  Log,  and  c)  Assess 
the  HS1  issues  and  plan  mitigation.  The  EHFA  output  forms  the  basis  for  the  project  HS1  Strategy 
and  Plan  and  provides  the  information  needed  to  develop  a  T arget  Audience  Description. 

The  level  of  detail  in  the 
analysis  depends  on  the 
infonnation  available;  EHFA 
is  particularly  suited  to 
situations  where  limited 
infonnation  is  available.  The 
analysis  is  based  upon  the 
provision  of  baseline 
information  which  will  be 
formed  from  the  definition  of 
the  emerging  concept  options 
to  the  proj  ect  and  details  of  the 
operational  requirement. 

EHFA  doesn’t  need  to  be 
complex  or  require  significant 
resources.  The  level  of  effort  needed  will  depend  on  the  size  and  complexity  of  the  UAS  project, 
the  expected  role  of  the  human  in  the  UAS,  and  the  quality  and  ease  of  access  to  suitable 
information  sources.  Where  limited  resources  are  available,  particularly  with  smaller  projects,  the 
technique  can  be  undertaken  effectively  by  one  person  with  both  the  appropriate  analysis  skills 
and  the  awareness  of  the  potential  scope  of  human  issues.  However,  experience  has  shown  that 
getting  the  correct  stakeholders  together  can  greatly  speed  the  process  and  achieve  better 
coverage  of  the  potential  human -related  risks  to  the  project  (UK  MoD  Acquisition  Operating 
Framework). 


Distribution  A:  Approved  for  public  release;  distribution  unlimited. 
88ABW  Clear  10/21/2013;  88ABW-2013-4442 


26 


2.2  Identify  and  Document  Human- 
Related  Issues 


Humans  form  a  key  component  of  operational 
capabilities.  Whether  a  system  is  generally  regarded  as 
‘unmanned’  or  is  thought  to  be  ‘fully  automated’, 
humans  perform  key  roles.  Human  roles  may  involve 
supporting  and  maintaining  equipment  and  also  making 
final  operational  decisions  such  as  weapons 
deployment,  targeting,  etc. 

Including  humans  in  an  otherwise  technology-centric 
system  will  generate  ‘human-related  issues.’  A  human- 
related  issue  is  considered  to  be  anything  that  requires 
the  attention  or  input  from  stakeholders,  and  decisions,  choices  or  trade-offs  between  competing 
requirements  to  be  made.  For  a  satisfactory  UAS  design  solution,  all  human-related  issues  need  to 
be  addressed  and  resolved  to  the  satisfaction  of  stakeholders  (UK  MoD  Def  Stan  00-250,  2008). 

The  best  way  to  identify  the  human-related  issues  is  to  conduct  a  focus  group  meeting  with  as 
many  of  the  stakeholders  as  possible.  Using  the  HS1  domains  as  a  prompt  for  areas  where  human- 
related  issues/risks  are  likely  to  exist,  capture  the  issues  in  a  brainstorming  fashion.  At  this  stage, 
analysis  is  not  necessary,  the  point  is  to  not  dismiss  any  comments  or  suggestions  made  by  the 
stakeholders.  Since  there  will  likely  be  a  lot  of  uncertainty,  many  assumptions  will  need  to  be 
made.  These  shoidd  be  as  explicit  as  possible  and  recorded  in  a  Human  Systems  Integration  Issue 
Log  (UK  MoD  Acquisition  Operating  Framework). 

2.3  Create  HSI  Issue  Log 

For  effective  UAS  project  management,  all  human-related  issues,  including  assumptions, 
constraints,  user  needs,  risks,  associated  mitigations,  opportunities  and  outcomes  that  arise  during 
the  design  of  the  UAS  must  be  recorded.  The  human-related  issues  should  be  maintained 
throughout  the  duration  of  the  contract  and  should  form  part  of  the  contract  deliverables.  An 
acceptable  vehicle  for  recording  such  issues  is  a  HSI  Issue  Log,  which  may  be  presented  in 
tabular  form  or  more  usually,  in  a  spreadsheet  or  database  form.  This  should  be  submitted  to  the 
acquirer  for  concurrence  early  in  the  contract  (UK  MoD  Def  Stan  00-250,  2008). 

2.4  Assess  Human-Related  Project  Issues 

Once  the  human-related  issues  have  been  captured  in  the  HSI  Issue  Log  they  need  to  be  evaluated 
and  assessed  for  likelihood  and  impact.  This  can  be  achieved  by  using  a  risk  management  matrix 
(or  suitable  national  substitute)  to  determine  the  relative  importance  of  each  issue  (see 
EUROCONTROL’s  The  Human  Factors  Case:  Guidance  for  Human  Factors  Integration  for  an 
example  human-related  issue  management  matrix).  If  an  issue  is  determined  to  have  potentially 
adverse  consequences,  it  is  qualified  as  a  risk.  Typically,  the  top  ten  issues  account  for  80%  of  the 
HSI  risk  on  any  particular  proj  ect. 

2.5  Mitigate  Human-Related  Project  Risks 

This  section  provides  a  list  of  possible  methods  for  mitigating  the  human-related  risks  that  will 
help  frame  the  HSI  Strategy  for  a  UAS  project.  The  issues  to  be  addressed  by  research,  studies, 
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and/or  data  collection  will  form  the  basis  of  the  Human  Systems  Integration  Plan  (HS1P). 
Possible  mitigation  strategies  include  (UK  MoD  Acquisition  Operating  Framework): 

•  Modify  performance  requirements 

•  Request  demonstrations  or  HS1  analysis  from  bidders 

•  Provide  project  funds  for  additional  research/studies/data  collection 

•  Highlight  areas  of  concern  in  a  Statement  of  Work  and  Business  Case 

•  Produce  a  HS1  data  requirements  list. 


3.0  Human  Views 

The  design  of  UAS  requires 
collaboration  between  a  diverse  range 
of  disciplines  to  embrace  all  areas  of 
system  design.  One  approach  to  dealing 
with  such  complexity  is  the  use  of 
Architecture  Frameworks.  UAS  often 
operate  as  part  of  distributed 
environments  and  collaborative 
settings.  They  require  the  specification 
not  only  of  the  information  systems, 
but  also  the  social,  organisational,  task, 
and  skill  structures  that  support 
complex  information  flows  and 
information  sharing. 

The  NATO  Human  View  (HV)  (NATO  TR-HFM-155:  Human  Systems  Integration  for  Network 
Centric  Warfare,  2010)  enables  an  understanding  of  the  human  role  in  systems/enterprise 
architectures.  It  provides  a  basis  for  decisions  by  stakeholders  by  providing  a  structured  linkage 
from  the  engineering  community  to  the  manpower,  personnel,  training,  and  human  factors 
engineering  communities.  It  provides  a  way  to  integrate  HSI  into  the  mainstream  acquisition  and 
systems  engineering  process  by  promoting  early  consideration  of  human  roles.  It  provides  early 
coordination  of  task  analysis  efforts  by  both  systems  engineering  and  human  factors  engineering 
teams.  By  capturing  the  necessary  decision  data  in  the  HV  and  integrating  this  view  with  the  rest  of 
the  architecture  framework,  the  improved  framework  provides  a  complete  set  of  attributes  of  the 
system  data. 

The  purpose  of  the  NATO  HV  in  UAS 
projects  is  to  capture  human  requirements 
and  to  inform  on  how  humans  interact 
within  the  systems.  The  HV  is  a 
supplementary  view  to  existing 
architectures,  providing  an  additional  set  of 
eight  products  that  augment  existing 
Architecture  Frameworks  required  of 
systems  engineers  (Figure  4). 

An  architecture  framework  defines  a 
common  approach  for  development, 
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presentation  and  integration  of  architecture  descriptions.  The  application  of  a  framework  enables 
architectures  to  contribute  more  effectively  to  building  interoperable  systems.  The  framework 
products  capture  multiple  aspects  of  a  complex  system  These  products  can  then  be  integrated 
together  to  evaluate  the  relationship  and  impact  of  the  corresponding  variables.  These  products 
should  be  considered  as  living  documents  and  need  to  be  iteratively  updated  as  the  system  design 
matures. 


Figure  4.  NATO  Human  View  products  overview 

(NATO  HSI  for  Network  Centric  Warfare) 

3.1  Create  HV-A:  Concept 

The  HV-A  is  a  conceptual,  high-level  representation  of  the  human  component  of  the  enterprise 
architecture  framework.  Its  purpose  is  to  visualize  and  facilitate  understanding  of  the  human 
dimension  in  relation  to  operational  demands  and  system  components.  It  serves  as  both  the  single 
point  of  reference  and  departure  to  depict  how  the  human  will  impact  performance  (mission 
success,  survivability,  supportability,  and  cost)  and  how  the  human  will  be  impacted  by  the 
system  design  and  operational  context  (personnel  survivability,  skill  demands,  training 
requirements,  workload  and  well-being). 

Information  requirements  may  include: 

•  Pictorial  depictions  of  the  system  and  its  human  component 

*  High  level  indicators  of  where  human  system  interactions  may  occur 

*  Textual  descriptions  of  the  overall  human  component  of  the  system 

•  Use  cases  which  describe  the  human  process. 
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3.2  Create  HV-B:  Constraints 

The  human  is  the  most  important  and  unique  component  within  a  UAS,  but  they  can  also 
potentially  be  the  weakest  link  or  highest  risk  component  when  the  system  design  fails  to  account 
for  human  constraints.  However,  the  latter  issue  can  be  mitigated  when  deliberate  attention  is 
given  to  accommodating  human  constraints  during  system  design.  Therefore  expressing  the 
capabilities  and  limitations  of  the  human  in  the  UAS  is  required.  HV-B  contains  the  set  of  data 
elements  that  are  used  to  adjust  the  expected  roles  and  functions.  It  acts  as  a  repository  for 
different  sets  of  constraints  that  may  affect  parameters  of  different  views  impacting  the  total 
system.  If  a  UAS  requires  a  human-machine  interface,  then  the  system  must  be  designed  to 
accommodate  the  human  in  such  a  way  as  to  account  for  the  human  limitations,  and  to 
support/maintain  the  human  to  at  least  a  minimum  acceptable  level. 

The  HV-B  has  six  sub  views: 

1)  Manpower  Projections  (HV-B1)  -  illustrates  predicted  manpower  requirements  for 
supporting  present  and  future  projects  that  contribute  to  larger  capabilities. 

Information  requirements  may  include: 

**  Understand  manpower  forecasting  to  allow  initial  adjustments  in  training,  recruiting, 
professional  development,  assignment  and  personnel  management 
**  Anticipate  impacts  (and  timeframe)  related  to  number(s)  of  personnel,  personnel  mix, 
military  occupation/trades  structure,  rank/level  distribution,  and 
postings/relocation(s)  of  personnel 

**  Ensure  sufficient  number  of  personnel  with  necessary  Knowledge,  Skills,  and 
Abilities  (KSA)  are  ‘ready  and  able’  to  support  fielding  of  future  programme. 

2)  Career  Progression  (HV-B2)  -  illustrates  career  progression  as  well  as  the  essential  tasks, 
skills,  and  knowledge  (and  proficiency  level)  required  for  a  given  job. 

Information  requirements  may  include: 

**  Impacts  of  alternative  system  and  capability  designs  on  career  progression 
**  Jobs  available  given  an  individual’s  current  job  and  occupation 
**  C ompetencies  required  for  each  individual  j  ob 
»*  Availability  of  individuals  with  necessary  competencies. 

3)  Establishment  Inventory  (HV-B3)  -  defines  current  number  of  personnel  by  rank  and  j  ob 
within  each  establishment. 

Information  requirements  may  include: 

»*  Forecast  of  trained  effective  strength 

Number  of  people  that  must  be  trained,  recruited,  etc.  to  fill  gaps  required  for  future 
years. 

4)  Personnel  Policy  (HV-B4)  -  personnel  policy  ensures  that  personnel  are  fairly  considered, 
properly  treated,  well  looked  after  and  supported  in  a  legal,  moral  and  ethical  manner. 
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Information  requirements  may  include: 

Department  policies  dealing  with  (governing)  human  resource  issues 

Human  resource  documents,  such  as  policies,  doctrine,  laws,  benefits,  pay,  Standard 

Operating  Procedures  (SOPs),  etc. 

5)  Health  Hazards  (HV-B5)  -  considers  the  design  features  and  operating  characteristics  of  a 
UAS  that  can  create  significant  risks  of  illness,  injury  or  death. 

Information  requirements  may  include  (CCOHS,  2009;  PSEPC,  2005): 

»*  System,  material,  environmental  or  task  hazard  assessment 
»♦  Air  quality  control  assessment 
»*  Noise/vibration  pollution  evaluation 
**  Impact  force,  shock,  LASER  protection 

»*  Workplace  Hazardous  Materials  Information  System  (WHMIS)  identification, 
classification,  and  evaluation  of  the  materials  or  chemicals  used  for  tasks 
**  Chemical,  Biological,  Radiological,  and  Nuclear  (CBRN)  protection 
**  Extremes  of  temperature,  etc. 

6)  Human  Characteristics  (HV-B6)  -  considers  the  characteristics  of  an  operator  and  movement 
capabilities  and  limitations  of  that  operator  under  various  operating  conditions. 

Information  requirements  may  include: 

»*  Aspects  such  as  anthropometric/medical  data;  reach  data;  range  of  motion  data; 
physical  strength  data;  human  sensory  (e.g.,  visual,  auditory,  tactile,  propioceptive, 
etc)  assessment;  speed  or  duration  of  activity  data;  cognitive  workload;  working 
memory  capacity;  ability  to  be  security  cleared;  personality;  motivation;  etc. 

3.3  Create  HV-C:  Tasks 

The  HV-C  describes  the  human-specific  activities,  i.e.,  the  tasks  that  have  been  assigned  to  the 
humans  in  a  UAS  over  its  entire  life  cycle.  It  also  considers  how  the  functions  are  decomposed 
into  tasks  and  the  dependencies  between  tasks. 

Information  requirements  may  include: 

**  Human-related  functions  in  a  UAS 

**  Allocation  of  functions  between  humans  and  technology 

»*  Decomposition  of  functions  into  tasks 

Task  descriptions  in  terms  of  various  criteria  and  the  KSA  requirements 
**  Depiction  of  inter-dependencies  between  different  tasks 
**  The  tools  required  to  accomplish  a  task 

»*  Human-machine  interface  design  guideline  on  the  basis  of  task  requirements. 


3.4  Create  HV-D:  Roles 

The  HV-D  describes  the  roles  that  have  been  defined  for  the  humans  interacting  with  the  UAS.  A 
role  represents  a  job  function  defining  specific  behaviour  within  the  context  of  an  organisation, 
with  some  associated  semantics  regarding  the  authority  and  responsibility  conferred  to  the  person 
in  the  role,  and  competencies  required  to  do  the  job. 
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Information  requirements  may  include: 

»*  Responsibility  -  accountability  and  commitment 
»*  Permissions  -  access  ability  of  an  individual  to  perform  a  specific  task 
»+  Competencies  -  the  quality  of  being  able  to  perform;  a  combination  of  knowledge, 
skills,  and  abilities 

**  Multiplicity  -  a  role  may  be  performed  by  a  human  or  by  multiple  humans  at  the  same 
time. 

3.5  Create  HV-E:  Human  Network 

The  HV-E  captures  the  human -to-human  communication  patterns  that  occur  as  a  result  of  ad  hoc 
or  deliberate  team  formation,  especially  teams  distributed  across  space  and  time. 

Information  requirements  may  include: 

**  Role  groupings  or  teams  formed,  including  the  physical  proximity  of  the  roles  and 
virtual  roles  included  for  specific  team  tasks 
**  Type  of  interaction  -  i.e.,  collaborate,  coordinate,  supervise,  etc. 

**  Team  cohesiveness  indicators  -  i.e.,  trust,  sharing,  etc. 

**  Team  performance  impacts  -  i.e.,  synchronisation  (battle  rhythm),  level  of  engagement 
(command  directed) 

**  Team  dependencies  -  i.e.,  frequency/degree  of  interaction  between  roles. 

3.6  Create  HV-F:  Training 

The  HV-F  is  a  detailed  accounting  of  how  training  requirements,  strategy,  and  implementation 
will  impact  the  human.  It  illustrates  the  instruction  or  education  and  on-the-job  or  unit  training 
required  to  provide  personnel  their  essential  tasks,  skills,  and  knowledge  to  meet  the  job 
requirements. 

Information  requirements  may  include: 

**  As  is  training  resources,  availability,  and  suitability 
**  Risk  imposed  by  to-be  operational  and  system  demands 
**  Cost  and  maturity  of  training  options  for  tradeoff  analysis 

**  Training  required  to  obtain  necessary  knowledge,  skills,  and  ability  to  support  career 
progression 

»*  Differentiation  of  basic,  intermediate,  or  advance  job  training;  operational  vs.  system 
specific  training;  and  individual  vs.  team  training. 


3.7  Create  HV-G:  Metrics 

There  is  a  wide  range  of  human-related  metrics  currently  in  use  and  different  approaches  to 
human-systems  performance  measurement  may  be  adopted  for  a  particular  UAS  project.  The  HV- 
G  provides  a  repository  for  human-related  values,  priorities  and  performance  criteria,  and  maps 
measures  to  other  HV  elements.  It  maps  high-level  (qualitative)  values  to  quantifiable 
performance  metrics  and  assessment  targets  and  maps  measurable  metrics  to  human  functions.  It 
provides  the  basis  for  human  factors  assessments  that  underpin  human-system  performance 
assessments  or  for  requirements  tracking  and  certification. 
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Information  requirements  may  include: 

**  Qualitative  human  factors  value  definitions 

»*  Quantitative  human  performance  metrics  (what  is  to  be  measured) 

»*  Target  values  (what  quantifiable  value  is  acceptable) 

**  Human  task-to -metrics  mapping 
**  Value  definition  links 
»*  Value  to  design  element  mapping 
**  Methods  of  compliance. 

3.8  Create  HV-H:  Human  Dynamics 

The  HV-H  captures  dynamic  aspects  of  human  system  components  defined  in  other  views.  These 
are  dynamic  aspects  in  the  sense  that  states,  conditions,  or  performance  parameters  may  change 
over  time,  or  as  a  result  of  triggering  events.  It  pulls  together  definitions  from  across  the  Human 
View  to  be  able  to  communicate  high  level  system  behaviour.  It  provides  inputs  to  human 
behaviour  and  executable  models  that  may  be  supported  by  simulation  tools.  There  are  many 
different  human  models  and  simulations  that  can  be  used  to  develop  dynamic  models;  this  view 
can  provide  stimuli  and  design  aspects  for  these  models. 

Information  requirements  may  include: 

•  States  (e.g.,  snapshots)  and  State  Changes: 

Organisational/team  structure 
**  Task/Role  assignments  to  people 
**  Team  interaction  modes 

Demands  on  collaboration  load  (e.g.,  need  to  spend  effort  in  building  shared 
awareness,  consensus-finding,  communicating) 

»*  Task  switches/interruptions 

•  Conditions  (e.g.,  triggering  events  or  situations;  scenarios) 

**  Critical  /  frequent  /  representative  /  typical  scenarios 
**  Operational  constraints  (e.g.,  extensive  heat  stress) 

**  Time  conditions:  sequence,  duration,  concurrency 

•  Performance  outcomes  (observed  or  predicted),  e.g., 

Workload 
**  Decision  speed 

»*  Team  interaction/collaboration  style 
**  Trust  in  commanders  intent 

Quality  of  shared  awareness/coordination/implicit  communication. 

4.0  Human-Related  Requirements  (HRRs) 

Human -related  requirements  derive  from  the  use  of  humans  as  part  of  a  system  that  delivers  a 
capability.  Their  purpose  is  to  provide  an  effective  means  of  coupling  human  issues  into  the 
systematic  framework  for  managing  requirements  during  acquisition.  HRRs  are  organized  under  the 
following  three  major  headings: 

1 .  Overarching  HRRs  which  are  system  requirements  that  arise  because  humans  are  part  of  a 
UAS.  For  example,  they  address  the  need  to  design  visual  displays  in  accordance  with  human 
performance  capabilities  and  limitations. 
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2.  Service-specific  HRRs  which  are  system  requirements  that  arise  because  a  particular  group  of 
military  personnel  are  part  of  the  system  (e.g..  Army,  Navy  or  Air  Force).  For  example,  they 
address  the  need  to  conform  to  current  Air  Force  organisational  hierarchies  in  the  manning 
solution. 

3.  Capability-specific  HRRs  which  are  system  requirements  that  arise  because  the  particular 
group  of  military  personnel  must  achieve  certain  functions  as  part  of  the  system.  For  example, 
they  address  the  need  for  equipment  users  to  locate  and  identify  targets  or  achieve  a  specified 
rate  of  fire  (UK  MoD  Def  Stan  00-250,  2008). 

4.1  Identify  and  Document  Human-Related  Assumptions  and 
Constraints 

The  contractor  must  ensure  that  all  human-related  assumptions  and  constraints  recorded  in  an  HSI 
Issue  Log  are  validated  at  agreed  stages  in  the  contract.  The  process  of  validation  must  confirm 
the  continued  applicability  of  each  constraint  and  the  assessed  impact  on  UAS  design  (UK  MoD 
Def  Stan  00-250,  2008). 

4.2  Identify  and  Document  Human-Related  Requirements,  and 
Compliance  Measures  and  Priorities 

As  with  any  other  type  of  requirement,  an  acceptance 
process  must  be  in  place  to  determine  whether  or  not  a 
FIRR  has  been  met.  The  contractor  needs  to  identify 
and  propose  appropriate  means  of  demonstrating 
compliance  with  each  requirement  in  the  contract  and 
submit  them  to  the  acquirer  for  agreement;  areas  of 
non-compliance  must  also  be  indicated.  Acceptable 
means  of  demonstrating  compliance  may  include,  but 
not  be  limited  to:  compliance  with  a  published 
standard,  conformity  to  an  agreed  process, 
measurement  or  inspection  of  solution  characteristics, 
static  test,  dynamic  test,  behavioural  test,  functional 
test,  physical  modeling  prototyping  or  trial  use  under 
defined  conditions.  The  contractor  must  demonstrate 
that  the  extent  and  quality  of  evidence  of  compliance 
to  be  provided  is  commensurate  with: 

•  The  degree  to  which  each  particular  requirement  impacts  the  UAS  design 

•  The  complexity  of  the  relevant  UAS  component(s)  or  subsystem(s) 

•  The  degree  of  project  risk  presented  by  the  requirement. 

Tests  involving  humans  are  more  costly  than  conventional  equipment  testing  and  are  subject  to 
practical  and  ethical  constraints;  however,  they  are  a  necessary  part  of  the  overall  process  of 
evaluation  and  acceptance  of  systems.  Cost-effective  approaches  to  contract  acceptance  of  HRRs 
are  described  in  Table  2. 
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Table  2.  Means  of  Accepting  Compliance  with  a  Requirement. 


Type 

Description 

Consensus  based  on 
Judgement 

Formal  agreement  by  stakeholder  based  on  subjective 
judgement  that  lower-level  requirements,  and/or  design 
detail  will  cause  the  requirement  to  be  met. 

Consensus  based  on 
Evidence 

Formal  agreement  by  stakeholders  that  evidence  presented 
(from  analysis,  modeling,  experiment,  survey,  or 
comparability)  justifies  the  belief  that  a  design  will  meet 
the  requirement,  or  that  a  solution  does  meet  the 
requirement. 

Design  Inspection 

Formal  scrutiny  of  descriptions  of  a  materiel  solution  at  an 
appropriate  level  of  detail  or  abstraction,  to  check  for 
conformance  with  a  requirement  or  specification.  In  this 
context,  the  term  ‘design’  is  not  confined  to  low-level 
detail.  It  may  apply  to  any  materiel  solution  description  that 
embodies  design  decisions,  even  if  the  decisions  are 
represented  by  lower-level  ‘requirements’. 

Functional  Demonstration 

Formal  demonstration  that  equipment  performs  the 
functions  in  a  requirement  or  specification. 

Task  Walkthrough 

Formal  presentation  of  task-support  facilities  to 
representative  users,  sequentially  as  if  the  task(s)  were 
being  performed,  with  criteria  based  upon  their  adequacy 
and  comprehensibility,  together  with  qualitative  measures 
of  user  acceptability. 

Operability  Trial 

Formal,  controlled,  structured  trials,  with  tasks  performed 
by  representative  users,  and  criteria  based  on  user 
performance  plus  subjective  user  reaction. 

4.3  Conduct  Trade-off  Analysis 

A  trade-off  is  a  decision-making  action  that  selects  various  requirements  and  alternative  solutions 
on  the  basis  of  net  benefit  to  the  stakeholder.  Successful  HS1  requires  the  contractor  to 
demonstrate  that  the  UAS  design  has  resulted  from  an  iterative  process  that  has  involved 
stakeholders,  Subject  Matter  Experts  (SMEs),  user  representatives  and  operators  from  the 
acquirer’s  organisation.  The  contractor  must  create  and  maintain  records  of  such  trade-off 
decision-making  processes  as  part  of  the  provision  of  traceability  records.  These  records  should 
form  part  of  the  contract  deliverables  (UK  MoD  Def  Stan  00-250,  2008). 

4.4  Incorporate  Human-Related  Requirements  into  Contract 
Specifications 

This  stage  involves  accepting  the  UAS  design  detailed  in  the  contractor’s  specification  and  ensure 
it  is  supported  by  tests  and  trials  to  provide  evidence  of  the  HRRs.  For  EIRRs  that  relate  to  human 
performance,  the  aim  is  to  ensure  that  suitable  tests  are  included  along  with  equipment 
performance  tests.  For  any  HRRs  that  have  not  been  subjected  to  such  tests,  and  refer  to 
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intangibles,  the  equipment  specification  is  not  sufficient.  There  must  be  an  accompanying 
contractual  requirement  for  how  the  contractor  will  engage  with  stakeholders,  and  what  types  of 
evidence  must  be  produced  to  support  stakeholder  acceptance  ensuring  the  non-testable  HRRs  are 
met  by  the  UAS  design. 

The  evidence  may  take  the  form  of  practical  results  from  trials  under  realistic  conditions  of  use  or 
documented  stakeholder  consensus.  Such  HRRs  must  be  worded  in  a  way  that  a  contractor 
understands  what  is  required  and  can  engage  with  stakeholders. 

Acceptance  of  a  delivered  UAS  is  matched  against  the  contract  specification,  which  will  contain 
testable  criteria  already  accepted  to  represent  the  requirements  in  the  document  of  system 
requirements  (e.g.,  System  Requirement  Document).  If  there  are  any  intangible  HRRs,  then  the 
System  Acquirer  will  seek  consensus  among  the  relevant  stakeholders  that  supporting  evidence 
presented  in  accordance  with  the  contract  has  demonstrated  compliance.  The  contractor  should 
seek  to  gain  this  consensus  as  early  as  possible  during  the  contract  period  and  plan  activities 
accordingly.  (UK  MoD  Def  Stan  00-250,  2008) 
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Post-Development  Decision  HSI  Activities 


HSI  Activity  Planning  is  the  next  stage  of  the  HSI  Process.  This  stage  is  divided  into  Management 
and  Technical  activities,  which  should  run  alongside  each  other  and  can  be  tailored  to  suit  specific 
project  requirements.  HSI  Management  Activities  relate  to  planning  what  to  do  and  when,  whilst 
T echnical  Activities  relate  to  doing  HSI.  T ogether  the  activities  of  HSI  provide  a  framework  for 
ensuring  the  human  element  of  a  UAS  is  considered  early  in  acquisition  and  that  the  required  level 
of  HSI  maturity  is  reached  before  the  development  of  a  system.  To  do  this,  adequate  resources  are 
needed  to  ensure  that  the  necessary  HSI  activities  are  budgeted  for,  scheduled  and  managed  as  part 
of  the  acquisition  process. 

This  section  provides  a  decomposition  of  HSI  Activity  Planning  including  key  HSI  outputs  and 
products.  Figure  5  illustrates  the  decomposition  of  the  steps  required  and  should  be  referenced  in 
the  following  sections:  1)  Management  Activities,  2)  Technical  Activities  and  3)  HSI  Outputs  and 
Products.  Recognising  these  activities  is  important  because  HSI  may  have  common  goals  and 
requirements  with  other  areas  of  systems  engineering  -  e.g.,  safety  and  Integrated  Logistics 
Support.  Aligning  activities  or  sharing  information  could  reduce  effort  -  e.g.,  the  same  task  analysis 
data  could  underpin  human-machine  interface  design,  training  needs  analysis  and  safety 
assessments  (UK  MoD  Through  Life  Capability  Management  [TLCM]  Handbook,  2010). 

HSI  Activity  Planning 


5.0  HSI  Management  Activities 


lj 


6.0  HSI  Technical  Activities 


5.1  HSI  Requirements  &  Acceptance 

1 6.1  Mission  Analysis 

5.2  HSI  Working  Group 

|  6.2  Functional  Analysis 

5.3  HSI  Plan 

|  6.3  Allocation  of  Functions 

|  6.4  Task  Analysis 


|  6.5  Design  Jobs,  Roles  &  Tasks 


6.6  Human  Reliability  Assessment 


6.7  Design  Equipment,  HMI  &  Workspace 

6.8  Develop  Training 


6.9  Performance  Assessment 


7.0  HSI  Outputs  and  Products 


I  7.1  Project  Life  Management  Plan 
|  7.2  Project  Test  and  Evaluation  Plan 


Figure  5.  Decomposition  of  post-development  decision  HSI  activities 
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5.0  Management  Activities 


The  management  of  HSI  needs  to  be  implemented  very  early  in  a  UAS  project  lifecycle.  HSI 
follows  a  defined  process,  with  clear  activities,  inputs  and  deliverables  throughout  the  project 
lifecycle.  The  size  or  criticality  of  these  inputs  will  depend  on  the  extent  and  severity  of  HSI  issues 
and  risks  identified  for  a  project  (UK  MoD  HFI  Process  Handbook,  2007). 

5.1  HSI  Requirements  and  Acceptance 

Requirements.  Most  UAS  are  critically  dependent  on  human-related  requirements  so  HSI  must 
identify  requirements  where  people  are  or  might  be  involved  via  User  Requirements.  In  some 
UAS  proj  ects  they  will  need  to  be  included  as  a  top-level  item,  in  others  they  can  be  aggregated 
with  other  concerns.  HSI  contributions  to  the  requirements  might  include  human  functions, 
human  support  functions,  user  and  organisational  constraints  and  measures  of  effectiveness  (UK 
MoD  HFI  Process  Model,  2007). 

•  Human-Related  Contribution  to  Requirements.  It  is  essential  that  human  performance 
concerns  are  reflected  in  high-level  capability  requirements  to  provide  the  “hooks”  for 
follow-on  detailed  requirements.  Since  it  is  people  working  with  the  procured 
equipment  that  deliver  the  desired  capability,  requirements  must  address  all  aspects 
that  impact  the  ability  of  people  to  effectively  work  with  the  equipment  as  well  as  any 
overarching  legal  or  moral  obligations  to  people. 

The  system  requirement,  supplied  to  contractors,  focuses  mainly  on  the  equipment  and  is 
formulated  in  terms  of  the  following  types  of  requirements:  1 )  functional  (i.e.,  what  the 
equipment  must  do),  2)  nonfunctional  (i.e.,  how  well  it  must  do  it),  and  3)  constraints  (i.e., 
limits  on  the  solution). 

A  subtype  of  nonfunctional  requirements,  HSI  requirements  are  specified  using  two 
additional  types  of  requirements:  1)  human  performance  (i.e.,  how  well  the  user  must 
perform  the  tasks  using  the  equipment  and  2)  process  (i.e.,  things  the  contractor  must  do). 
Making  human  performance  requirements  explicit  is  critical  to  ensuring  they  are  tested  and 
considered  as  part  of  the  equipment  acceptance  decision.  Process  requirements  are  often 
used  when  functional  or  performance  requirements  cannot  be  clearly  specified.  HSI  shoidd 
contribute  requirements  at  a  comparable  level  of  detail  to  those  from  other  areas  (Harrison 
&  Forster,  2003). 

•  Human-Machine  Interface  Requirements.  In  general,  the  largest  set  of  HSI-related 
requirements  deals  with  the  human-machine  interface  since  the  interface  mediates  much  of 
the  equipment’s  impact  on  the  user.  For  information-rich  systems,  it  may  be  prudent  to 
develop  the  human-machine  interface  requirements  prior  to  the  main  functional 
requirements  through  an  interactive  requirements  prototyping  exercise  with  users  (Harrison 
&  Forster,  2003). 

•  Human  Systems  Integration  Process  Requirements.  Requirements  for  conducting  HSI 
have  an  important  role  in  defence  contracts.  Mandating  processes  to  generate  evidence 
about  human  aspects  of  the  UAS  can  reduce  risk  by  enabling  better  coupling  of  contractor 
results  with  the  procuring  authority’s  own  internal  HSI  processes  and  programme.  In 
addition,  since  the  cost  of  HSI-related  work  can  be  a  significant  part  of  a  contractor’s 
budget,  mandating  key  evidence-producing  activities  ensures  all  competitor’s  proposals  are 
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comparable.  It  is  also  sensible  to  require  contractors  to  demonstrate  how  proposed  UAS 
designs  have  been  influenced  by  HSI  considerations  (Harrison  &  Forster,  2003). 

Acceptance.  The  most  critical  check  on  whether  requirements  are  appropriate  is  whether 
acceptance  criteria  have  been  sufficiently  identified.  Some  typical  types  of  HSI  acceptance  tests 
include  design  inspection,  functional  demonstration,  task  walkthroughs,  and  operability  trials 
(previously  defined  in  Table  2,  Section  4.2).  The  aim  during  HSI  acceptance  is  to  properly  test 
attributes  of  the  equipment  for  which  the  contractor  is  responsible,  including  the  ability  to 
integrate  with  the  human  component  of  the  UAS.  Early  defined  requirements  and  acceptance 
criteria  should  ensure  that  contractors  provide  more  effective  equipment  and  systems  that  fully 
meet  the  operational  requirements. 

Acceptance  must  specify  how  contractors  will  be  assessed  against  the  HSI  requirements  and 
constraints  in  terms  of  the  characteristics  of  the  UAS  (including  conformance  to  standards)  and 
performance.  HSI  acceptance  criteria  tend  to  take  two  forms:  those  dealing  with  design 
characteristics  and  those  dealing  with  human  performance  as  a  function  of  system  performance. 

In  the  early  stages,  HSI  requirements  may  not  be  specified  in  any  detail  and  the  requirement  may 
actually  be  to  carry  out  requirements  definition  studies  in  the  HSI  domains.  Gradually  a  set  of 
derived  HSI  requirements  should  be  produced  that  are  based  upon  the  evolving  design  (UK  MoD 
HFI  Process  Handbook,  2007). 

5.2  HSI  Working  Group 

A  HSI  Working  Group  (HSIWG) 
serves  as  a  forum  for  interchange  of 
ideas  and  information  and  also  helps 
resolve  conflicts  between  different 
specialist  requirements.  This  forum  is 
important  for  coordination  between 
HSI  stakeholders  so  it  is  necessary  to 
establish  it  as  soon  as  possible.  The 
next  steps  are  to  define  the  terms  of 
reference,  obtain  support  from  the 
Acquirer  with  a  clear  line  of  reporting 
to  them,  include  user 
representatives/other  technical  areas  of 
the  project,  and  include  stakeholders  with  an  interest  in  human-related  aspects  of  the  UAS.  The 
HSIWG  functions  to  proactively  resolve  issues  and  conflicting  requirements;  when  an  impasse 
occurs,  the  working  group  brings  the  issue  to  the  attention  of  the  Acquirer  leadership  for  decision. 
Ideally,  the  HSIWG  should  run  throughout  the  project  and  shoidd  retain  a  reasonably  stable 
membership.  Sustaining  the  group  during  fielding  of  the  UAS  will  allow  for  coordination  of 
feedback  from  UAS  users,  such  as  operators  and  maintainers,  on  gaps  and  opportunities. 

5.3  Human  Systems  Integration  Plan 

Because  each  UAS  is  unique,  individual  programmes  will  naturally  emphasize  some  domain  areas 
more  than  others.  Human  Systems  Integration  Plan  (HSIP)  content  will  depend  upon  the  nature  of 
the  particular  UAS  being  developed.  Consequently,  an  organisation  may  tailor  the  HSIP  to  their 
particular  circumstance  and  better  satisfy  the  specific  organisational  needs.  The  HSIP  is  best 
submitted  as  an  evolutionary  and  continuous  product  in  conjunction  with  the  UAS 
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engineering  plan  and  system  lifecycle  management  plan  (or  national  equivalent  plans);  however, 
the  HSIP  can  also  be  developed  as  a  stand-alone  document. 


Type  of  Information  in  a  HSIP: 

•  HS1  issues 

•  HS1  constraints 

•  HS1  studies,  actions  and  mitigation  strategies 
for  each  significant  issue 

•  Organisational  chart 

•  Dependencies  between  organisations  and 
project  activities  in  conducting  HSI  activities 

•  Key  milestones,  deliverables  and  timescales 

•  Extent  of  need  for  user  (i.e.,  operator) 
participation 

•  Method  for  including  HSI  in  system  level 
trade-offs 

•  Method  for  monitoring  and  controlling 
progress  against  the  plan 


The  HSIP  should  support  HSI  throughout  the  life  cycle  of  the  UAS,  taking  into  consideration 
programme  needs  from  capability  planning.  The  HSIP  should  be  updated  and  refined  annually 
with  the  UAS  engineering  plan  to  account  for  evolving  risks  and  improvement  initiatives.  If  it  is 
not  possible  to  update  yearly,  it  should  at  least  be  refined  at  important  system  development 
points.  If  possible,  a  lull  HSIP  should  be  included  as  an  annex  in  the  UAS  engineering  plan,  but 
as  previously  mentioned,  it  can  be  developed  as  a  stand-alone  plan.  Regardless,  it  is 
fundamentally  important  for  those  responsible  for  HSI  on  a  project  to  develop  a  HSIP  for  the 
success  of  the  UAS  (United  States  Air  Force,  2008). 

6.0  Technical  Activities 

This  section  will  introduce  the  HSI  Technical  Activities  that  may  be  carried  out  during  a  UAS 
project.  Many  of  these  Technical  Activities  will  require  specialist  input.  However,  it  is  also 
necessary  for  those  managing  HSI  to  have  some  understanding  of  the  need  for  function  and  output 
of  these  activities  as  part  of  the  HSI  Management  process.  HSI  Technical  Activities  ensure 
‘designing  for  use’  objectives  can  be  met.  Additionally,  HSI  is  an  integral  part  of  systems 
engineering  and  so  should  support  other  specialist  technical  activities. 

The  EHFA  forms  a  starting  point  by  allowing  key  HSI  risks,  issues,  assumptions  and  constraints  to 
be  identified.  The  previous  work  on  Human  Views  (section  3.0)  will  infonn  the  Technical 
Activities,  and  the  results  of  the  activities  should  be  used  to  update  applicable  Human  Views. 
Although  the  Technical  Activities  are  sequentially  described  here,  the  execution  of  these  activities 
is  iterative.  Iteration  is  not  only  appropriate  but  also  expected.  New  information  is  created  by 
individual  Technical  Activities,  and  typically  this  information  takes  the  form  of  questions  with 
respect  to  requirements,  analysed  risks  or  opportunities.  Such  questions  should  be  resolved  by 
reapplication  of  Technical  Activities.  Appendix  A  provides  a  Cross-Walk  matrix  and  Justification 
table  mapping  each  Technical  Activity  with  applicable  Human  Views. 
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HSI  Technical  Activities  draw  upon  a  range  of  specialist  methods  and  tools  generally  used  by 
qualified  practitioners.  It  is  important  from  the  HSI  Management  perspective  to  be  familiar  with  the 
types  of  design  and  evaluation  activities  that  should  occur. 

6.1  Mission  Analysis 

Mission  Analysis  is  important  in  deciding  what  the  human  does.  The  operational  scenario 
provides  information  that  supports  EHFA  and  enables  generation  of  human-system  assumptions. 

It  also  contributes  support  to  manning  and  personnel  requirements.  Such  scenarios  are  likely  to 
form  the  basis  of  future  acceptance  testing  for  fitness  of  purpose,  including  calculations  and 
assessment  of  human  performance  and  workload,  etc.  They  must  be  based  on  a  comprehensive 
understanding  of  operators’  other  tasks  (not  related  to  the  equipment/capability  in  question)  and 
of  service  doctrine  and  training  expertise  (UK  MoD  HFI  Process  Handbook,  2007).  [Relevant 
HVs:  HV-A  Concept,  HV-B  Constraints,  HV-C  Tasks,  HV-D  Roles,  and  HV-G  Metrics]. 

6.2  Functional  Analysis 

Functional  analysis  is  the  analysis  of  UAS  functions.  Functions  describe  relatively  broad  activities 
that  may  be  implemented  by  personnel  alone  (e.g.,  deploy  equipment),  by  equipment  alone  (e.g., 
self-test/equipment  circuitry),  or,  as  in  most  cases,  by  some  combination  of  both  (e.g.,  pre -flight 
checks).  Functions  can  be  instantaneous  (e.g.,  fire  missile)  or  prolonged  (e.g.,  monitor  radar), 
simple  (e.g.,  start  engines)  or  complex  (e.g.,  assess  tactical  situation).  At  a  certain  level  of  detail, 
functions  become  indistinguishable  from  tasks;  there  are  no  clear-cut  rules  for  making  this 
distinction  (UK  MoD  Def  Stan  00-250,  2008).  [Relevant  HVs:  HV-A  Concept,  HV-C  Tasks,  and 
HV-D  Roles]. 

6.3  Allocation  of  Functions 

Function  Allocation  refers  to  the  task  of  deciding  the  distribution  of  functions  between  the 
operator  and  equipment.  Considered  one  of  the  most  important  human-centred  design  principles, 
these  design  decisions  determine  the  extent  to  which  a  given  j  ob,  task,  function  or  responsibility 
is  to  be  automated  or  assigned  to  human  performance. 

The  decisions  are  based  on  many  factors,  such  as  relative  capabilities  and  limitations  of  humans 
versus  technology  in  terms  of  reliability,  speed,  accuracy,  strength,  flexibility  of  response, 
financial  cost,  the  importance  of  successful  or  timely  accomplishment  of  tasks  and  user  well¬ 
being.  They  should  not  simply  be  based  on  determining  which  functions  the  technology  is 
capable  of  performing  and  then  simply  allocating  the  remaining  functions  to  users,  relying  on 
their  flexibility  to  make  the  system  work.  The  resulting  human  functions  should  form  a 
meaningful  set  of  tasks.  Users  should  always  be  involved  in  these  decisions  as  described  in  the 
user-centred  design  process  (ISO  13407:1999). 

[Relevant  HVs:  HV-C  Tasks  and  HV-D  Roles]. 

6.4  Task  Analysis 

A  comprehensive  view  and  clear  understanding  of  the 
users’  typical  tasks  and  cognitive  processes  are 
fundamental  to  most  aspects  of  HSI  and  feeds  into 
many  other  system  design  activities.  The  scope  of 
what  the  operators  and  maintainers  are  required  to  do 
is  captured  in  a  task  description  (which  is  intimately 
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linked  with  the  operational  requirement).  Task  analysis  then  explores  the  implications  of  these 
tasks  in  terms  of  the  operator’s  ability  to  undertake  them.  For  systems  where  human  functions  are 
predominantly  “cognitive”,  the  methods  of  analysis  captures  this  essential  human  activity. 
Analytical  methods  such  as  mission  function  task  analysis,  cognitive  task  analysis,  cognitive 
work  analysis,  and  hierarchical  goal  analysis  can  provide  the  user  interface  communication, 
visual  display  and  control  requirements  needed  for  system  design.  They  also  provide  the  means 
to  capture  more  detailed  knowledge  from  subject  matter  experts  for  embedding  in  a  knowledge- 
based  system  (Banbury,  et  al.,  2007;  Hou,  et  al.,  2011;  UK  MoD  HF1  Process  Handbook,  2007; 
UK  MoD  TLCM  Handbook,  2010).  [Relevant  HVs:  HV-A  Concept,  HV-C  Tasks,  HV-D  Roles, 
and  HV-F  Training], 

6.5  Design  Jobs,  Roles,  and  Tasks 

Job  analysis  is  the  process  of  systematically  investigating  and  evaluating  the  attributes  of  a  job  in 
terms  of  tasks,  procedures,  and  responsibilities  and  personal  attributes.  Job  design  involves 
deciding  what  tasks  will  be  performed  by  which  personnel,  how  tasks  will  be  grouped  together 
and  allocated,  and  how  individuals  will  relate  to  each  other  so  that  their  work  can  be  coordinated. 
This  ensures  that  tasks  and  roles  allocated  to  a  job  are  appropriately  structured  and  achievable 
(UK  MoD  HFI  Process  Handbook,  2007;  TLCM,  2010).  [Relevant  HVs:  HV-A  Concept,  HV-B 
Constraints,  HV-C  Tasks,  HV-D  Roles,  HV-E  Human  Network,  and  HV-F  Training], 

6.6  Human  Reliability  Assessment 


Human  Reliability  Assessment  (HRA)  is  a 
specialist  activity,  using  knowledge  about  the 
expected  UAS  design  and  its  likely  failures  to 
define  causal  chains  showing  what  factors 
would  combine  to  create  particular  hazards. 

HRA  identifies  the  likelihood  of  human  error 
in  UAS  designs  and  the  impact  of  such  errors 
(UK  MoD  HFI  Process  Handbook,  2007). 

[Relevant  HVs:  HV-B  Constraints  and  HV-H 
Human  Dynamics]. 

6.7  Design  Equipment,  HMI,  and  Workspace 

This  is  concerned  with  the  design  of  operational  equipment  including  displays  (visual  and 
auditory),  controls,  human-computer  interfaces,  alarms  and  warnings,  user  manuals  and 
operational  facilities  within  workspaces.  It  also  addresses  hand  tools,  work  clothing,  and  selection 
of  Commercial  Off  the  Shelf  (COTS),  Military  Off  the  Shelf  (MOTS)  or  Government  Off  the 
Shelf  (GOTS)  -  i.e.,  preexisting  -  equipment.  The  design  of  workspaces  should  be  concerned 
with  meeting  the  functional  needs  of  the  system  and  personnel  whilst  minimising  stress  and 
maintaining  optimal  levels  of  performance  (UK  MoD  TLCM  Handbook,  2010).  [Relevant  HVs: 
HV-A  Concept,  HV-G  Metrics,  and  HV-H  Human  Dynamics]. 

6.8  Develop  Training 

Training  Needs  Analysis  assesses  training  requirements  arising  as  a  result  of  new  equipment 
procurement,  doctrinal  change,  organisational  change,  or  changes  to  policy.  It  generally  includes 
a  comparison  of  different  training  methods  and  equipment  with  a  with  a  view  to  recommending 


Distribution  A:  Approved  for  public  release;  distribution  unlimited. 
88ABW  Clear  10/21/2013;  88ABW-2013-4442 


42 


the  optimum  training  system  (UK  MoD  TCLM  Handbook,  2010).  [Relevant  HVs:  HV-C  Tasks, 
HV-D  Roles,  HV-F  Training,  and  HV-G  Metrics]. 

6.9  Performance  Analysis 

Human  performance  related  issues  and  risks,  such  as  usability,  error,  situation  awareness, 
workload,  and  team  coordination  should  be  addressed  in  analyses  to  ensure  that  the  intended 
users  will  be  able  to  use  the  system  in  an  operational  environment  and  achieve  required  standards 
of  task  performance.  A  wide  range  of  techniques  for  predicting  and  measuring  aspects  of  human 
performance  are  available.  Access  to  intended  users  may  need  to  be  provided  to  support  ‘person 
in  the  loop’  performance  trials.  Computer  modeling  can  be  a  cost-effective  way  of  predicting 
human  performance.  The  data  from  this  type  of  analysis  will  consequently  inform  and  aid 
decisions  about  human-machine  interface  design,  allocation  of  functions,  etc.  (UK  MoD  TCLM 
Handbook,  2010).  [Relevant  HVs:  HV-A  Concept,  HV-B  Constraints,  HV-C  Tasks,  HV-D  Roles, 
HV-E  Human  Network,  HV-G  Metrics,  and  HV-H  Human  Dynamics]. 


7.0  HSI  Outputs  and  Products 

To  ensure  HSI  aspects  are  fully  considered  as  part  of  broader  UAS  project  management  and 
technical  development,  it  is  important  to  include  a  human  component  in  other  project  activities  and 
their  documentation.  Two  key  examples  are  a  Project  Life  Management  Plan  and  a  Project  Test  and 
Evaluation  Plan. 

7.1  Project  Life  Management  Plan 

A  Project  Life  Management  Plan  gives  a  whole  life  perspective  on  UAS  project  objectives, 
assumptions,  plans  and  resources.  It  draws  upon  a  set  of  documents  including  the  following  HSI 
examples: 


•  HSI  Management  Plan  and  Strategy 

•  Key  HSI  decisions 

•  HS1WG  constitution  and  responsibilities 

•  Division  of  responsibility  for  HSI  activities 

•  HSI  testing  and  evaluation  plans  and  results 

•  Procedures  for  managing/sharing  HSI  data 

•  HSI  audit  results  following  introduction  to  service 

•  HSI  management  strategy  for  upgrades 

•  HSI  risks,  issues,  assumptions  and  constraints. 

7.2  Project  Test  and  Evaluation  Plan 

A  Project  Test  and  Evaluation  Plan  defines  how  the  project  will  ensure  that  the  required  UAS  is 
being  produced  and  then  confirm  that  it  has  been  produced.  Those  aspects  of  the  UAS  that  relate 
to  integration  between  human  and  equipment  elements  require  HSI  input  to  the  Project  Test  and 
Evaluation  Plan.  Such  input  may  be  integrated  within  the  plan  or  developed  as  a  standalone 
section.  It  should  include  the  following: 
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•  HSI  Management  Plan 

•  HSI  acceptance  processes  and  procedures  (including  specifying  appropriate 
military/user  participants  for  trials) 

•  HSI  T esting  and  Evaluation  Plan  results 

•  Outputs  from  HS1WG  meetings. 
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Conclusion 


Human  Systems  Integration  (HSI)  is  a  robust  process  integral  to  systems  engineering  by  which  to  design 
and  develop  UAS  designs  that  effectively  and  affordably  address  human  capabilities  and  limitations.  It 
involves  the  identification  and  tradeoff  of  the  human-related  issues  that  could  impact  acquisition 
processes.  Its  major  value  is  the  integration  of  five  individual  domains  consisting  of  Manpower  and 
Personnel,  Training,  Human  Factors  Engineering,  Safety  and  Health,  and  Organisational  and  Social.  HSI 
integrates  and  facilitates  the  trade-offs  among  these  five  domains  and  between  the  domains  and  the  other 
performance  requirements  without  replacing  individual  domain  activities. 

HSI  must  be  applied  during  development  and  acquisition  of  UAS  and  related  equipment  to  integrate 
personnel  (operator,  user,  or  maintainer)  effectively  into  the  design  of  the  system.  The  total  system 
includes  not  only  the  prime  mission  equipment,  but  also  the  people  who  operate,  maintain  and  support  the 
system;  the  training  and  training  devices;  and  the  operational  and  support  infrastructure. 

UAS  technology  continues  to  rapidly  evolve  in  the  face  of  relatively  static  human  performance  capabilities 
and  limitations,  increasing  the  potential  for  mismatches  between  people  and  technology.  System 
developers  need  to  ensure  that  UAS  are  designed  to  take  human  considerations  into  account,  thereby 
allowing  them  to  push  the  technology,  human,  and  other  support  resources  to  their  collective  limit  in 
pursuit  of  mission  capability.  Given  humans  continue  to  have  significant  impacts  on  the  operational 
effectiveness  of  UAS,  they  must  be  viewed  as  a  central  component  of  UAS. 
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Appendix  A 

Table  3.  Technical  Activity  and  Human  View  Cross-Walk 


HSI  Technical  Activity 


Mission  Analysis 


Functional  Analysis 


Allocation  of  Functions 

Task  Analysis 

Design  Jobs,  Roles,  and  Tasks 

Human  Reliability  Assessment 

Design  Equipment,  HMI,  and  Workplace 

Develop  Training 

Performance  Analysis 

Human  View 

HV-A  Concept  -  A  high-level  representation  of  the  human  component 

of  the  enterprise  architecture  framework.  Its  purpose  is  to  visualize  and 
facilitate  understanding  of  the  human  dimension  in  relation  to  operational 
demands  and  system  components  (NATO  201 0). 

X 

X 

X 

X 

X 

X 

HV-B  Constraints  -  These  are  sets  of  characteristics  that  are  used  to 
adjust  the  expected  roles  and  tasks  based  on  the  capabilities  and 
limitations  of  the  human  in  the  system  (NATO  2010). 

X 

X 

X 

X 

HV-C  T asks  -  Describes  the  human  activities  that  are  assigned  to  the 
human  in  the  system  with  information  requirements  including  human- 
related  functions  in  a  system,  allocation  of  functions  between  humans 
and  machines  and  decomposition  of  functions  into  tasks  (NATO  2010). 

X 

X 

X 

X 

X 

X 

X 

HV-D  Roles  -  Describes  the  roles  that  have  been  defined  for  the 
humans  interacting  with  the  system  with  information  requirements 
including  the  access  ability  of  an  individual  to  perform  a  specific  task  and 
the  quality  of  being  able  to  perform  -  a  combination  of  knowledge,  skills, 
and  attributes  (NATO  2010). 

X 

X 

X 

X 

X 

X 

X 

HV-E  Human  Network-  Captures  the  human  to  human  communication 
patterns  that  occur  as  a  result  of  ad  hoc  or  deliberate  team  formation, 
especially  teams  distributed  across  space  and  time  (NATO  2010). 

X 

X 

HV-F  T raining  -  A  detailed  accounting  of  how  training  requirements, 
strategy,  and  implementation  will  impact  the  human.  It  illustrates  the 
instruction  or  education  and  on-the-job  training  required  to  provide 
personnel  their  essential  tasks,  skills,  and  knowledge  to  meet  the  job 
requirements  (NATO  2010) 

X 

X 

X 

HV-G  Metrics  -  Provides  a  repository  for  human-related  values,  priorities 
and  performance  criteria.  It  may  map  high-level  (qualitative)  values  to 
quantifiable  performance  metrics  and  assessment  targets  or  it  may  map 
measurable  metrics  to  human  performance  specifications  (NATO  2010). 

X 

X 

X 

X 

HV-H  Human  Dynamics  -  Captures  dynamic  aspects  of  human  system 
components.  These  are  dynamic  in  the  sense  that  states,  conditions,  or 
performance  parameters  may  change  over  time,  or  as  a  result  of 
triggering  events  (NATO  201 0) 

X 

X 

X 
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Justification  of  Mapping 


Mission  Analysis 

Mission  Analysis  is  important  in  deciding  what  the  human  does.  It  considers  a  comprehensive  set  of 
operational  mission  profiles.  Each  mission  profile  is  divided  into  a  number  of  phases  and  related 
operating  modes.  Each  mode  is  then  divided  into  task  steps  which  are  categorized  in  terms  of  frequency, 
criticality,  demands,  etc.  For  each  identified  task  the  associated  system  functions  are  identified.  This 
constitutes  the  allocation  of  the  task  to  the  system  component,  human  component,  or  sharing  of  the 
function  between  the  two. 


Human  View 

Justification 

HV-A  Concept 

A  high-level  representation  of  the  human  component  of  the  enterprise 
architecture  framework.  Its  purpose  is  to  visualize  and  facilitate  understanding  of 
the  human  dimension  in  relation  to  operational  demands  and  system 
components. 

EIV-B  Constraints 

These  are  sets  of  characteristics  that  are  used  to  adjust  the  expected  roles  and 

tasks  based  on  the  capabilities  and  limitations  of  the  human  in  the  system 

HV-C  Tasks 

Describes  the  human  activities  that  are  assigned  to  the  human  in  the  system 

with  information  requirements  including  human-related  functions  in  a  system, 
allocation  of  functions  between  humans  and  machines  and  decomposition  of 
functions  into  tasks. 

ETV-D  Roles 

Describes  the  roles  that  have  been  defined  for  the  humans  interacting  with 
the  system  with  information  requirements  including  the  access  ability  of  an 
individual  to  perform  a  specific  task  and  the  quality  of  being  able  to  perform  -  a 
combination  of  knowledge,  skills,  and  attributes. 

HV-G  Metrics 

Provides  a  repository  for  human-related  values,  priorities  and  performance 
criteria.  It  may  map  high-level  (qualitative)  values  to  quantifiable  performance 
metrics  and  assessment  targets  or  it  may  map  measurable  metrics  to  human 
performance  specifications. 
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Functional  Analysis 


Functional  Analysis  is  the  analysis  of  UAS  functions.  Functions  describe  relatively  broad  activities  that 
may  be  implemented  by  personnel  alone,  by  equipment  alone,  or  by  some  combination  of  both.  Functions 
can  be  instantaneous  (e.g.,  fire  missile),  prolonged  (e.g.,  monitor  radar),  simple  (e.g.,  start  engine),  or 
complex  (e.g.,  asses  tactical  situation). 


Human  View 

Justification 

FIV-A  Concept 

A  high-level  representation  of  the  human  component  of  the  enterprise  architecture 
framework.  Its  purpose  is  to  visualize  and  facilitate  understanding  of  the 
human  dimension  in  relation  to  operational  demands  and  system 
components. 

HV-C  Tasks 

Describes  the  human  activities  that  are  assigned  to  the  human  in  the  system  with 
information  requirements  including  human-related  functions  in  a  system, 

allocation  of  functions  between  humans  and  machines  and  decomposition  of 
functions  into  tasks. 

HV-D  Roles 

Describes  the  roles  that  have  been  defined  for  the  humans  interacting  with 
the  system  with  information  requirements  including  the  access  ability  of  an 
individual  to  perform  a  specific  task  and  the  quality  of  being  able  to  perform  -  a 
combination  of  knowledge,  skills,  and  attributes. 

Allocation  of  Functions 

Allocation  of  Functions  refers  to  the  task  of  deciding  the  distribution  of  functions  between  the  operator 
and  the  equipment.  Design  decision  determine  the  extent  to  which  a  given  job,  task,  function,  or 
responsibility  is  to  be  automated  or  assigned  to  human  performance. 


Human  View 

Justification 

HV-C  Tasks 

Describes  the  human  activities  that  are  assigned  to  the  human  in  the  system  with 
information  requirements  including  human-related  functions  in  a  system, 

allocation  of  functions  between  humans  and  machines  and  decomposition  of 
functions  into  tasks. 

HV-D  Roles 

Describes  the  roles  that  have  been  defined  for  the  humans  interacting  with 
the  system  with  information  requirements  including  the  access  ability  of  an 
individual  to  perform  a  specific  task  and  the  quality  of  being  able  to  perform  -  a 
combination  of  knowledge,  skills,  and  attributes. 
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Task  Analysis 


Task  Analysis  techniques  are  used  to  understand  and  represent  human  and  system  performance  in  a 
particular  task  or  scenario.  The  scope  of  what  the  operators  and  maintainers  are  required  to  do  is  captured 
in  a  task  description  (which  is  linked  with  the  operational  requirement).  Task  Analysis  then  explores  the 
implications  of  the  tasks  in  terms  of  the  operator’s  ability  to  undertake  them. 


Human  View 

Justification 

HV-A  Concept 

A  high-level  representation  of  the  human  component  of  the  enterprise 
architecture  framework.  Its  purpose  is  to  visualize  and  facilitate  understanding 
of  the  human  dimension  in  relation  to  operational  demands  and  system 
components. 

HV-C  Tasks 

Describes  the  human  activities  that  are  assigned  to  the  human  in  the  system 

with  information  requirements  including  human-related  functions  in  a  system, 
allocation  of  functions  between  humans  and  machines  and  decomposition  of 
functions  into  tasks. 

HV-D  Roles 

Describes  the  roles  that  have  been  defined  for  the  humans  interacting  with 
the  system  with  information  requirements  including  the  access  ability  of  an 
individual  to  perform  a  specific  task  and  the  quality  of  being  able  to  perform  -  a 
combination  of  knowledge,  skills,  and  attributes. 

HV-F  Training 

A  detailed  accounting  of  how  training  requirements,  strategy,  and 
implementation  will  impact  the  human.  It  illustrates  the  instruction  or  education 
and  on-the-job  training  required  to  provide  personnel  their  essential  tasks,  skills, 
and  knowledge  to  meet  the  job  requirements. 
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Design  Jobs,  Roles,  and  Tasks 


Job  analysis  is  the  process  of  systematically  investigating  and  evaluating  the  attributes  of  a  job  in  terms  of 
tasks,  procedures,  and  responsibilities  and  personal  attributes.  Job  design  involves  deciding  what  tasks 
will  be  performed  by  which  personnel,  how  tasks  will  be  grouped  together  and  allocated,  and  how 
individuals  will  relate  to  each  other  so  that  their  work  can  be  coordinated. 


Human  View 

Justification 

HV-A  Concept 

A  high-level  representation  of  the  human  component  of  the  enterprise 
architecture  framework.  Its  purpose  is  to  visualize  and  facilitate  understanding 
of  the  human  dimension  in  relation  to  operational  demands  and  system 
components. 

HV-B  Constraints 

These  are  sets  of  characteristics  that  are  used  to  adjust  the  expected  roles  and 
tasks  based  on  the  capabilities  and  limitations  of  the  human  in  the  system. 

HV-C  Tasks 

Describes  the  human  activities  that  are  assigned  to  the  human  in  the  system 

with  information  requirements  including  human-related  functions  in  a  system, 
allocation  of  functions  between  humans  and  machines  and  decomposition  of 
functions  into  tasks. 

HV-D  Roles 

Describes  the  roles  that  have  been  defined  for  the  humans  interacting  with 
the  system  with  information  requirements  including  the  access  ability  of  an 
individual  to  perform  a  specific  task  and  the  quality  of  being  able  to  perform  -  a 
combination  of  knowledge,  skills,  and  attributes. 

HV-E  Human 
Network 

Captures  the  human  to  human  communication  patterns  that  occur  as  a  result  ol 
ad  hoc  or  deliberate  team  formation,  especially  teams  distributed  across  space  and 
time. 

HV-F  Training 

A  detailed  accounting  of  how  training  requirements,  strategy,  and 
implementation  will  impact  the  human.  It  illustrates  the  instruction  or 
education  and  on-the-job  training  required  to  provide  personnel  their  essential 
tasks,  skills,  and  knowledge  to  meet  the  job  requirements. 
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Human  Reliability  Assessment 


Human  Reliability  Assessment  must  be  considered  whenever  the  human  component  in  a  system 
contributes  to  system  safety  or  system  reliability.  This  may  occur  when  operator  actions  are  required  to 
maintain  safety  or  when  operator  performance  can  directly  influence  overall  system  performance.  HRA 
identifies  the  likelihood  of  human  error  in  UAS  design  and  the  impact  of  such  errors. 


Human  View  Justification 


HV-A  Concept 

A  high-level  representation  of  the  human  component  of  the  enterprise 
architecture  framework.  Its  purpose  is  to  visualize  and  facilitate 
understanding  of  the  human  dimension  in  relation  to  operational  demands 
and  system  components. 

HV-H  Human 
Dynamics 

Captures  dynamic  aspects  of  human  system  components.  These  are  dynamic  in 
the  sense  that  states,  conditions,  or  performance  parameters  may  change  over 
time,  or  as  a  result  of  triggering  events. 

Design  Equipment,  HMI,  and  Workspace 

This  is  concerned  with  the  design  of  operational  equipment  including  displays  (visual  and  auditory), 
controls,  human-computer  interfaces,  alarms  and  warning,  user  manuals  and  operational  facilities  within 
workspaces.  The  design  of  workspaces  shoidd  be  concerned  with  meeting  the  functional  needs  of  the 
system  and  personnel  whilst  minimising  stress  and  maintaining  optimal  level  of  performance. 


Human  View  Justification 


Human  View 

Justification 

HV-B  Constraints 

These  are  sets  of  characteristics  that  are  used  to  adjust  the  expected  roles  and 
tasks  based  on  the  capabilities  and  limitations  of  the  human  in  the  system. 

HV-G  Metrics 

Provides  a  repository  for  human-related  values,  priorities  and  performance 
criteria.  It  may  map  high-level  (qualitative)  values  to  quantifiable  performance 
metrics  and  assessment  targets  or  it  may  map  measurable  metrics  to  human 
performance  specifications. 

HV-H  Human 
Dynamics 

Captures  dynamic  aspects  of  human  system  components.  These  are  dynamic  in 
the  sense  that  states,  conditions,  or  performance  parameters  may  change  over  time, 
or  as  a  result  of  triggering  events. 
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Develop  Training 


Training  Needs  Analysis  is  to  identify  the  skills  and  knowledge  that  users  require  to  perform  their  jobs.  It 
assesses  training  requirements  arising  as  a  result  of  new  equipment  procurement,  doctrinal  change, 
organisational  change,  or  changes  to  policy.  It  generally  includes  a  comparison  of  different  training 
methods  and  equipment  with  a  view  to  recommending  the  optimum  training  system. 


Human  View 

Justification 

HV-C  Tasks 

Describes  the  human  activities  that  are  assigned  to  the  human  in  the  system  with 

information  requirements  including  human-related  functions  in  a  system, 

allocation  of  functions  between  humans  and  machines  and  decomposition  of 
functions  into  tasks. 

HV-D  Roles 

Describes  the  roles  that  have  been  defined  for  the  humans  interacting  with  the 
system  with  information  requirements  including  the  access  ability  of  an 
individual  to  perform  a  specific  task  and  the  quality  of  being  able  to 
perform  -  a  combination  of  knowledge,  skills,  and  attributes. 

HV-F  Training 

A  detailed  accounting  of  how  training  requirements,  strategy,  and 
implementation  will  impact  the  human.  It  illustrates  the  instruction  or 
education  and  on-the-job  training  required  to  provide  personnel  their 
essential  tasks,  skills,  and  knowledge  to  meet  the  job  requirements. 

HV-G  Metrics 

Provides  a  repository  for  human-related  values,  priorities  and  performance 
criteria.  It  may  map  high-level  (qualitative)  values  to  quantifiable 
performance  metrics  and  assessment  targets  or  it  may  map  measurable 
metrics  to  human  performance  specifications. 
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Performance  Analysis 


Human  performance-related  issues  and  risks,  such  as  usability,  error,  situation  awareness,  workload,  and 
team  coordination  should  be  addressed  in  analyses  to  ensure  that  the  intended  users  will  be  able  to  use  the 
system  in  an  operational  environment  and  achieve  required  standards  of  task  performance.  Computer 
modeling  can  be  a  cost-effective  way  of  predicting  human  performance.  The  data  from  this  type  of 
analysis  will  consequently  inform  and  aid  decisions  about  human-machine  interface  design,  allocation  of 
functions,  etc. 


Human  View  Justification 


Human  View 

Justification 

HV-A  Concept 

A  high-level  representation  of  the  human  component  of  the  enterprise  architecture 
framework.  Its  purpose  is  to  visualize  and  facilitate  understanding  of  the 
human  dimension  in  relation  to  operational  demands  and  system  components. 

HV-B  Constraints 

These  are  sets  of  characteristics  that  are  used  to  adjust  the  expected  roles  and 
tasks  based  on  the  capabilities  and  limitations  of  the  human  in  the  system. 

HV-C  Tasks 

Describes  the  human  activities  that  are  assigned  to  the  human  in  the  system 
with  information  requirements  including  human-related  functions  in  a  system, 

allocation  of  functions  between  humans  and  machines  and  decomposition  of 
functions  into  tasks. 

HV-D  Roles 

Describes  the  roles  that  have  been  defined  for  the  humans  interacting  with  the 
system  with  information  requirements  including  the  access  ability  of  an 
individual  to  perform  a  specific  task  and  the  quality  of  being  able  to  perform  - 
a  combination  of  knowledge,  skills,  and  attributes. 

HV-E  Human 

Network 

Captures  the  human  to  human  communication  patterns  that  occur  as  a  result  of 
ad  hoc  or  deliberate  team  formation,  especially  teams  distributed  across  space 
and  time. 

HV-G  Metrics 

Provides  a  repository  for  human-related  values,  priorities  and  performance  criteria. 

It  may  map  high-level  (qualitative)  values  to  quantifiable  performance  metrics 
and  assessment  targets  or  it  may  map  measurable  metrics  to  human 
performance  specifications. 

HV-H  Human 

Dynamics 

Captures  dynamic  aspects  of  human  system  components.  These  are  dynamic  in 
the  sense  that  states,  conditions,  or  performance  parameters  may  change  over  time, 
or  as  a  result  of  triggering  events. 
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Acronyms 


CBRN 

COTS 


DoD 

DoDAF 


EHFA 


FI  NAS 


GCS 

GOTS 


HFE 

HFI 

HMI 

HRA 

HRR 

HSI 

HSIP 

HSIWG 

HV 


JCGUAS 


KSA 


MoD 

MOTS 


C 

Chemical,  Biological,  Radiological  and  Nuclear 
Commercial  Off  the  Shelf 


D 

Department  of  Defense 

Department  of  Defense  Architectural  Framework 

E 

Early  Human  Factors  Analysis 

F 

Flight  in  Non-Segregated  Airspace 

G 


Ground  Control  Station 
Government  Off  the  Shelf 


H 


Human  Factors  Engineering 
Human  Factors  Integration 
Human-Machine  Interface 
Human  Reliability  Assessment 
Human-Related  Requirement 
Human  Systems  Integration 
Human  Systems  Integration  Plan 
Human  Systems  Integration  Working  Group 
Human  View 


J 

Joint  Capability  Group  for  Unmanned  Aircraft  Systems 

K 

Knowledge,  Skills,  and  Abilities 

M 


Ministry  of  Defence 
Military  Off  the  Shelf 
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NATO 

NTSB 


SME 

SOP 


TAD 

TLCM 


UAS 


WG 

WHMIS 


N 

North  Atlantic  Treaty  Organisation 
National  Transportation  Safety  Board 

S 

Subject  Matter  Expert 
Standard  Operating  Procedure 

T 


Target  Audience  Description 
Through-Life  Capability  Management 

U 


Unmanned  Aircraft  System 


W 


Working  Group 

Workplace  Hazardous  Materials  Information  System 
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